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Traffic Service Position System No. 1 
Recent Developments: 


An Overview 


By R. E. STAEHLER and W. S. HAYWARD, Jr. 


(Manuscript received December 11, 1978) 


This paper presents an overview of the Traffic Service Position 
System No. 1 in terms of the objectives and design philosophy of the 
new features that have been continuously added to the system since 
its initial introduction into service in the Bell System. It also serves 
as an introduction to the detailed technical papers that follow. 


Il. INTRODUCTION 


Almost all of the telephones in the United States can be used to dial 
toll calls directly over the Direct Distance Dialing network. Neverthe- 
less, approximately 15 percent of the total number of toll messages are 
placed with the assistance of toll operators. These toll calls include 
person-to-person, collect, credit card, hotel-originated calls, calls from 
coin stations, operator-dialed calls, and certain international calls. On 
an average business day, more than 13.1 million calls are placed 
through operators, and, in addition, there are over 5.2 million operator 
contacts for assistance and originating number identification. At year- 
end 1978, about 60,000 operators were employed to give this service. 


1.1 Capabilities of initial design’ 


The Traffic Service Position System No. 1 (tsps No. 1) was intro- 
duced into the field in January, 1969 (in Morristown, New Jersey) as 
an operator service system that could be used in conjunction with 
almost all Bell System local and toll switching systems to allow 
customers to dial their own operator-assisted calls and to relieve the 
operator of many tedious tasks required by cord switchboards. The 
basic objective of the initial system design was to automate routine 
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functions so that the operator could concentrate on communicating 
with customers, using human judgment, and establishing calls. The 
features of the early installations were designed to handle basic func- 
tions for coin and non-coin calls, such as automatic call timing and 
recording, recording of originating directory number, and recording 
and transmission of customer-dialed numbers. Since TsPs employs 
stored program control, it was intended that additional features would 
be added to automate an ever-increasing number of functions as 
advances in technology made these technically and economically via- 
ble. Typical calls not included in the initial design were conference 
calls, mobile and marine calls, inward to operator calls, and special 
handling of hotel and motel calls. 

TSPs No. 1 provides each operator with a cordless, electronic console 
which, through indicating lamps and pushbuttons, establishes an op- 
erator-machine interface for use in automation of routine functions. 
TSPs No. 1 increases the number of calls an operator can handle and 
also quickly makes auxiliary information available which may be 
needed to serve the telephone customers better. 

Customers benefit from these features. Because number recording 
and timing calculations are performed by the computer-like system, 
the delay of manual operation is eliminated and calls go through faster. 
Calls are also billed more accurately. On coin calls, initial and overtime 
charge calculations are instantly available. 

Operating companies benefit because they can provide operator 
assistance more efficiently. They can, therefore, handle increased 
traffic levels with the same number of operators. Furthermore, they 
are able to manage the work force more effectively because of the 
improved administrative features and to have the added flexibility to 
locate Operator Office Groups at convenient locations. 

Operators benefit by a more attractive working environment, an 
equitable distribution of calls to their positions, and the satisfaction of 
serving their customers better. 

From 1969 through 1977, five additional issues of generic programs 
have expanded the feature content in TsPs No. 1. There are now about 
135 systems in the continental United States. Over 80 percent of Bell 
System customers and a large number of customers served by other 
companies are now served by Tsps. It is estimated that, within the 
next three years, the Bell System coverage will exceed 90 percent, 
providing almost universal availability. 


1.2 Additions to capability 


Since, as shown in Fig. 1, TspPs utilizes stored program control, new 
features have been continuously and easily introduced into the system. 
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Fig. 1—Basic tsps No. 1. 


1.2.1 Hotel /motel 


One of these features is the automation of hotel/motel billing. When 
a guest at a hotel or motel has made toll calls during his or her stay, 
the guest must pay the charges for these calls when checking out. 
These charges are now automatically computed (including taxes) for 
each call by Tsps. Within a few seconds, the charges are printed on a 
dedicated teletypewriter on the hotel/motel premises. If the hotel/ 
motel does not have enough toll calling to justify a dedicated teletype- 
writer, the charges are printed at a telephone company billing center 
where a clerk telephones the hotel/motel and gives the charges orally— 
within a few minutes. 

Other businesses such as convention centers, marinas, and brokerage 
houses may also employ this time and charge information feature to 
allocate telephone charges to their customers. 


1.2.2 International call handling 


Another of these features is the partial automation of international 
call handling. When a customer who is not served by an office equipped 
to handle International Direct Distance Dialing (IDDD) calls wishes to 
place an international call, he or she simply dials 0 and gives the 
desired international number to the TsPs operator. The operator then 
indicates to TSPS via key action on the console that this call is an 
international call and then enters the number. For a station-to-station 
call, the TsPs operator releases from the call, and the system automat- 
ically forwards the call to a gateway switching office, which then sends 
the call overseas via satellite or cable. If the call is made on a credit 
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card, a collect, or a person-to-person basis, the TSPS operator processes 
the rest of the call in the same manner as a domestic call. 

In the case where a customer is served by local offices having IpppD 
capabilities, the customer who dials a 011 prefix followed by the 
country code digit and the national number will have his or her call 
forwarded by Tsps without the assistance of an operator. If the cus- 
tomer dials a 01 prefix followed by the country code and the national 
number, or if the customer dials 010 only, the TSPs operator will be 
connected to assist the customer. 


1.2.3 Others 


In addition, a number of other features such as time and charge 
quotations for non-coin (non-hotel) calls, recording of charges for 
directory assistance calls, and maintenance and administration im- 
provements have been introduced into the system. 


1.3 Hardware improvements 
1.3.1 Semiconductor memory 


The original Tsps design utilized piggyback twistor memory based 
on magnetic storage elements for program and call store. Advances in 
technology have made it possible to replace the piggyback twistor 
memory with a semiconductor memory resulting in major reductions 
in cost, space, and energy consumption. 


ll. MOST RECENT NEEDS 
2.1 Extension to sparsely populated areas 


Densely populated areas that generate a large amount of operator- 
assisted traffic easily justify the capital expenditures for a Tsps, but in 
a sparsely populated area, the toll switching center is small, and 
relatively few operators are needed. Savings in operating costs are not 
sufficient to balance the traffic-insensitive cost of the TsPs central 
processor. Nevertheless, the improvements provided by TSPS are ex- 
tremely desirable in these sparsely populated areas. Not only can 
service be improved, but the difficulties of maintaining a sufficient 
number of operators, day and night, in small isolated teams could be 
eliminated. 


2.1.1 Remote Trunk Arrangement? 


To economically provide the benefits of Tsps to the sparsely popu- 
lated areas, the Remote Trunk Arrangement (RTA), as shown in Fig. 
2, has been developed to bring TSPs service from a distant TSPs to one 
of these locations. 

The RTA equipment is located at a toll office in the rural area, with 
a concentrator network providing the talking path between the incom- 
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ing trunks and the TsPs operator. Data links (called peripheral control 
links, PCLs) connect the RTA equipment with the centrally located base 
TSPs processor which retains the control, logic, records, and centralized 
access to operators. The operator traffic from one or more RTAS is 
added to the traffic of a centrally located base TsPs to generate the 
load necessary to utilize a TSPS economically. 

An improved electronic operator console (the 100C) combining 
training and service features has been designed to be used for both 
local and remote applications. This configuration is designated Posi- 
tion Subsystem (pss) No. 2. The distance from the farthest RTA 
through the Tsps processor to the farthest Operator Office Group can 
total as much as 1000 miles, so that one TspPs can handle the traffic 
from a large geographical area. 


2.1.2 Design aspects*° 

The articles in this issue covering the RTA design aspects include 
overall description, operational characteristics, transmission consider- 
ations, and hardware and software implementation. 
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Fig. 2—Remote Trunk Arrangement. 
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2.2 Relieving operators of routine coin toll call functions 


As advances were made in technology, it became increasingly ap- 
parent that routine coin toll call functions, such as charge quoting and 
coin collection, could be fully automated. Confirmation of the technical 
and economic viability of this approach was obtained via in-depth 
systems engineering studies supported by test results on laboratory 
feasibility models. 


2.2.1 Automated Coin Toll Service 


To further the benefits of Tsps, the Automated Coin Toll Service 
(ACTS), shown in Fig. 3, has been developed to provide TsPs with the 
ability to process station paid coin calls automatically, including initial 
period notification, overtime charge notification, and quotations on 
time and charges for non-coin originated calls. For communicating 
with the customer, additional equipment was provided with TsPs which 
could store digitally encoded speech segments, concatenate these 
speech segments into sentences, and monitor the coin deposits. 

Stored program was added not only to control the new equipment 
in performing the coin service tasks but also for interfacing the new 
equipment with the existing TSPs. 


2.2.2 Human factor studies® 


The complex nature of the customer-machine interface in ACTS 
prompted the implementation of a three-month human factors trial in 
Chicago, Illinois. The trial was designed to provide AcTs-like service 
using TSPS operators plus a skeletonized prototype of the ACTS equip- 
ment. 
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Fig. 3—Automated Coin Toll Service. 
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Fig. 4—Remote Trunk Arrangement in Utica, New York. 


The TsPs operators were instructed to respond only to dial signals 
from customers and transmit the initial period length and call charges 
computed by Tsps to an auxiliary minicomputer via a teletypewriter. 
The minicomputer in turn sent instructions to the prototype ACTS 
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equipment to fabricate sentences (initial time interval and call charges) 
which were transmitted directly to the customer. The coin deposits 
made by customers in response to the announcements were then 
transmitted by the TSPs operator to the minicomputer via the tele- 
typewriter. Subsequent prompting announcements and the timing of 
such announcements were controlled by the minicomputer. 

The results of this trial established the basic human factors design 
parameters essential to the development of a system that would 
satisfactorily complete coin toll calls without operator assistance. 


2.2.3 Design aspects 


The articles in this issue covering the ACTS design aspects include 
details of the human factors trial, system description, operational 
characteristics, and hardware and software implementation. 


Il. STATUS 
3.1 Remote Trunk Arrangement 


The first RTA system was placed in service in Syracuse-Utica, New 
York, in May, 1976. The RTA equipment in Utica is shown in Fig. 4. 
As of year-end 1978, 120 RTAs and 60 pss No. 2s are in service, with 
about 20 more RTAs and 10 pss No. 2s in various stages of installation. 





Fig. 5—Automated Coin Toll Service in Phoenix, Arizona. 
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Fig. 6—An Operator Office Group in Phoenix, Arizona. 


3.2 Automated Coin Toll Service 


The first AcTS system was placed in service in Phoenix, Arizona, in 
November, 1977. The acts equipment in Phoenix is shown in Fig. 5. 

As of year-end 1978, 3 ACTS were in service, with about 20 more in 
various stages of installation. By 1981, it is estimated that Acts will be 
installed in all Tsps sites that have significant coin traffic, and that 
most of the coin paid calls in the Bell System will be handled by the 
ACTS equipment. 

An Operator Office Group located in the suburbs of Phoenix is 
shown in Fig. 6. 


IV. PERFORMANCE 


Performance data from the RTA, PSs No. 2, and ACTs sites indicate 
that all design objectives have been achieved. 


V. FUTURE TRENDS** 


There are plans to exploit the stored program concept further by 
augmenting the operational software programs to utilize the basic ACTS 
equipment for handling credit card, collect, and third-number calling 
without operator intervention. 


Vi. SUMMARY 


This paper has presented a general background for RTA and ACTS 
additions to Tsps No. 1 as an introduction to the technical papers that 
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follow. While all design details could not possibly be included, the 
papers in this issue provide a comprehensive overview of the greatly 
enhanced utilization of Tsps No. 1. 
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Traffic Service Position System No. 1: 


Remote Trunk Arrangement: Overall 
Description and Operational Characteristics 


By S. M. BAUMAN, R. S. DiPIETRO, and R. J. JAEGER Jr. 


(Manuscript received December 11, 1978) 


This paper is an introduction to the Remote Trunk Arrangement 
feature of the Traffic Service Position System. The design permits the 
TsPs trunk circuit, which connects the subscriber to the operator, to 
be located in a distant, rural location. All the logic, records, control, 
and centralized access to the operators remains at the base unit. The 
Remote Trunk Arrangement is controlled over a data link and up to 
eight RTA subsystems can be extended from a single Tsps base unit. 
The addition of the RTA feature, expansion of the geographical area 
served by TSPs, and the necessity for handling special operator service 
traffic, affected several Tsps design parameters and required the 
addition of several new features. These supporting features and the 
operational characteristics and design aims of RTA are described. 


|. INTRODUCTION 


The Traffic Service Position System No. 1 (Tsps) helps the operator 
more efficiently handle toll calls such as collect, credit card, charge to 
third number, and coin toll calls. Key elements of the system design 
were to have all calls served by a single large team of operators, to 
divide the large team into smaller groups of a maximum of 62 operators 
for administrative purposes, to permit the location of the groups 
remote from the base unit near good labor markets, and to achieve 
high concentrations of traffic to fully utilize the expensive equipment 
needed to handle the complex, detailed toll calls. 

The initial market for Tsps was in large metropolitan areas having 
high traffic density and high employee turnover. As the needs of the 
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metropolitan areas were being met, it became apparent that the 
benefits of TsPS would be desirable in more sparsely populated areas 
for two major reasons. The first was that, because of their small size— 
50 position switchboards and smaller—rural operator teams are less 
cost effective. Moreover, there is a special need to increase efficiency 
in off-hours when average traffic might not require the services of a 
single operator. Providing the supporting personnel facilities for small 
groups added to the cost. The second reason for providing TSPs service 
in rural areas was to provide uniformity of service to all customers. An 
increasingly mobile population anticipates the same type of telephone 
service nationwide. 

To provide the benefits of TSPs operation in rural areas, several 
approaches were investigated, including a scaled-down version of TSPS 
and the incorporation of TsPs features in a local switching system. The 
solution chosen is the Remote Trunk Arrangement (RTA). As the name 
implies, the design permits the Tsps trunk circuit, which provides the 
brief transmission bridge to the operator, to be located in a distant, 
rural location. All the logic, records, control, and centralized access to 
operators remain at the base unit. The RTA is controlled over a data 
link and provides all the benefits and features inherent in Tsps. Since 
traffic from a number of RTAS can be handled by a single base unit in 
addition to the traffic at the base, efficient utilization of the relatively 
powerful Tsps is achievable. Also, existing TSPs installations not using 
all the available capacity can be more fully utilized by reaching out 
into surrounding rural areas. 

One RTA can provide up to 496 Tsps trunks which connect to the 
base over 64 voice circuits. Control of the RTA is over triplicated data 
lines. To ensure continuity of service, voice transmission and data 
facilities are split over diverse routings. The transmission objective of 
having the operator voice levels equivalent to local operator service 
limits the maximum allowable distance between the most remote RTA 
to the most distant operator to 1000 miles via the base unit. Various 
transmission factors establish this limit as explained in Ref. 2. 

The original design of TSPS provided for remoting operator groups 
using a special version of T1 carrier to provide both voice and data 
tailored to Tsps. This arrangement has been extensively applied, but 
it poses a limitation to some operating companies because the maxi- 
mum remoting distance is 80 miles and T carrier routes are not always 
available to the desired operator location. Therefore, as part of the 
RTA development, the data link capability for controlling the RTA was 
so designed that it could also control a remotely located operator 
group. This data link arrangement has been named the Peripheral 
Control Link (PcL). The voice and data circuits from the base to the 
operator positions can now be provided by using circuits on any 
standard transmission facility. Also, a new version of the TSPs console 
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was developed to improve the circuit control mechanisms and permit 
consoles to be used for both training and service. The new console is 
designated 100C, and the combination of the pc. with the 100C is 
called Position Subsystem (pss) No. 2. Position Subsystem No. 2 can 
be used for both local and remote applications and supersedes the 
original pss No. 1. 100C consoles can be located as far as 1000 miles 
from the base if no RTAs are served by the base. 

Several system problems unique to the rural environment had to be 
solved as part of the RTA development. Closing a rural cord switchboard 
unit often removed the only 24-hour service unit in the area. Off-hour 
business service calls, repair service calls, alarms from unattended 
telephone offices, busy line verification calls, calls from postpay coin 
telephones and inward assistance calls have been traditionally handled 
by such switchboards. After due consideration, some of these functions 
are now handled by new administrative arrangements and some by 
new designs. A description of the RTA supporting feature designs is 
contained in Section III of this paper. 

The RTA overall description appears in the following sections and 
the reader is encouraged to consult Refs. 1 and 2 for more details about 
the hardware and software design. 


ll. OVERALL DESCRIPTION OF RTA/PSS NO. 2 


A simplified view of the RTA is shown in Fig. 1. The TSPs, or base 
unit, is shown bridging onto toll-connecting trunks between local and 
toll switching offices. In a similar way, the RTA bridges onto the toll- 
connecting trunks which home on the toll switching office serving the 
rural area. The RTA is controlled from the base unit by means of a 
data link. Voice grade connections between the RTA and the base unit 
allow the base unit to provide operator assistance as well as other 
voice frequency functions (e.g., MF digit reception and outpulsing). In 
this way, all traffic in the complex can be handled by a single operator 
team and common service circuits. Also, the substantial cost of the 
TSPS common control equipment is shared by all traffic in the complex. 

Although Fig. 1 shows only one RTA, the system is designed to 
accommodate up to eight RTAs in a single complex. In this way, it has 
proven possible to pool the traffic of a large geographic area and in 
some cases to justify a TSPS/RTA complex where a single location is 
not a candidate for its own TSPS. 

Figure 2 shows a more detailed view of RTA. The TSPs base unit is 
shown in the lower portion of the figure. An RTA, many miles distant, 
is shown at the top of the figure. 

The RTA works under control of the base unit SPC processor and 
connects to service circuits and positions via the Tsps base unit 
network. At the RTA location are trunks, a switching network (the 
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Fig. 2—Detailed diagram tsps Remote Trunk Arrangement. 





concentrator), a test frame, and scanning and signal distribution units. 
The RTA connects to the base unit over the Peripheral Control Link 
and over a number of Base-Remote (BR) trunks for voice connection 
to operators and service circuits. 
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Solid-state components are used almost exclusively for RTA circuits, 
and most of these consist of medium-scale TTL integrated circuits. The 
concentrator matrix, while controlled by integrated circuits, uses small 
crossbar switches. The compact physical design shown in Fig. 3 is due 
to this extensive use of integrated circuits. Less than one 20-ft by 20-ft 
building bay is required to contain an RTA of up to 496 trunks plus up 
to 64 base-remote trunks. Most of this space is occupied by transmis- 
sion equipment and trunk frames. 

The concentrator to BR trunk connections are engineered to provide 
a blockage of probability 0.001 to provide minimum delay in connecting 
operators and service circuits to calls. Since an operator is required on 
a connection for only a small fraction of the total call duration, a high 
concentration ratio can be achieved. While this ratio may vary from 
one site to another, 8:1 is a typical number. This is the reason for 
supplying a maximum of 64 base-remote trunks. One way of looking at 
the concentrator is that it is another stage of switching on the base 
network with very long links (BR trunks) between the first and second 
stages. 

The basic traffic capabilities of TSps remain essentially unchanged 
with the addition of RTA. All Tsps features are available to both Tsps 
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Fig. 3—RTA frames. 
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base unit customers and RTA customers. The customer will not be able 
to detect whether service is provided directly by a base unit or through 
an RTA. 


2.1 Peripheral control link 


The two-way data capability between the base unit and RTA is 
provided by a group of elements known collectively as the Peripheral 
Control Link (PcL) (Fig. 4). The pct includes the data link itself, the 
circuits which interface with the data link (group gate and remote data 
circuit), and the scanning and signal distribution units. The data 
facilities are standard four-wire voice channels operated full duplex 
and use 2400-b/s data modems. The Group Gate and Remote Data 
Circuit perform extensive error detection and provide necessary par- 
allel/serial conversions. Each message over the data link is acknowl- 
edged by the receiving end. Messages are retransmitted if mutilated in 
the original transmission. For reliability, data facilities are provided 
over two geographically independent routes. Three data lines are 
provided, with one line serving as a switchable spare for two active 
lines. : 

When used with an RTA, the PCL provides the ability to control, via 
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the signal distributor, the RTA trunk circuits and concentrator. By 
means of the scanner, the PCL can monitor trunks and report changes 
of state. This control and monitoring, together with the data commu- 
nication function of the PCL, provides a set of general capabilities. For 
the pss No. 2, the signal distributor and scanner of the PCL are used to 
control console lamps and detect operator keying actions. 

The Position and Trunk Scanner (PTs) is located at the remote end 
of the pc. Its function is to autonomously scan key reports from PSs 
No. 2 positions and pp pulses and supervisory state information from 
trunks in RTA. This information is reported to the spc 1A over the 
data link. The trunks are scanned every 12.5 ms by the pts which 
compares this information with last-look data in its memory. For base 
trunks, timing of supervisory changes of state for the purpose of 
detecting flashes and disconnects, and filtering out hits (a spurious 
change of state which must be ignored) is under program control. 
However, for remote trunks, since delays in transmission of successive 
changes of state over the data link could distort the relative timing, hit 
detection and filtering is done for RTA by the pts. This is accomplished 
by demanding that changes in supervisory state of trunks persist for at 
least two successive scans before reporting them to the base unit via 
the PCL. 

The Signal Distributor (sp), located at the remote site, is responsible, 
for distributing orders to remote trunks, the concentrator, test buffers, 
a test frame, and to 100C positions. The sp has several features 
designed to make efficient use of the data link. Commonly used groups 
of orders from the base to the remote location for control of positions 
are combined. Hence, one order transmitted from the base has the 
effect of executing many orders at the remote end. For example, there 
is a release order which causes all lighted lamps at a 100C position to 
be extinguished. This saves much data link capacity. A second design 
feature allows all trunks at an RTA to be initialized with one order. 
Since there can be as many as 496 trunks at an RTA, this could save as 
many as 1487 relay orders (three orders per trunk) over the data link. 
This feaure is used for system initialization. Customer conversations 
at the time of initialization must be preserved. Therefore, provisions 
were made in the hardware such that trunks in the talking state are 
not initialized. 


2.2 Circuits controlled by the PCL 

The RTA concentrator is controlled from the base unit by call 
processing software through the Pct signal distributor. The small 
crossbar switches are arranged in a two-stage network. 

The rTA trunk circuits generally provide the same capabilities as 
the Tsps base unit trunk circuits. However, because they are controlled. 


REMOTE TRUNK ARRANGEMENT) 1125 


over the data link, they differ significantly in design from base unit 
trunks. They have greater logic capability for sending coded flashing 
signals and for timing incoming flashing signals. They also have greatly 
augmented features for testing of the trunk units. With the use of 
integrated circuits and miniature relays, these complex trunks are 
similar in size to the functionally simpler Tsps trunks. Potential dis- 
tortion of the relative timing between consecutive orders during pe- 
riods of data link congestion necessitated the design of remote trunks 
with a unique feature. All remote trunks have the ability to generate 
from one to five winks from a single command. Winks of precise time 
duration are needed for coin station control using multiwink signaling. 

As described earlier, the PCL has also been designed to function with 
new operator position equipment. The new 100C console contains the 
necessary electronics to decode information transmitted from the 
signal distributor, to light or extinguish the appropriate lamps, and to 
remember the state of all the lamps on the position. The position 
electronics also detects operator keying actions and provides data to 
the PCL scanner in appropriate form. Only a few pairs of wires are 
necessary to connect a position console to the pcL. Thus, the addition 
of positions to a position subsystem is a relatively simple matter. 

The RTA/Pss No. 2 fault recognition and diagnostic programs make 
use of three maintenance circuits controlled by the pcL. The mainte- 
nance buffers are used to set and reset circuit states for reconfiguration 
and testing purposes. A Diagnostic Controller Circuit is activated over 
the PcL and used to execute sequences of RTA/PSS No. 2 diagnostic 
tests stored within its read only memory (Rom). Failing test results are 
reported back to the base via the pcL and formated for TTY output to 
the craft. The third maintenance circuit under PCL control is the Test 
and Display Circuit. This circuit provides the craftsforce at the remote 
site with a manual interface for control of trunk and position trans- 
mission test equipment. It also provides a status display of PcL and 
controlled circuit equipment. 


2.3 Peripheral control link configurations 


The rTA/PSS No. 2 system design provides for up to 15 peripheral 
control links to a base tsps. There is a maximum of 8 RTA subsystems 
per TSPS and a maximum of 8 operator groups per TSPS. 

The RTA and pss No. 2 subsystems were each designed to operate 
when located at a 1000-mile maximum distance from the .TSPs base 
unit. However, for proper transmission of voice and tones, a 1000-mile 
limit is applied to the sum of the farthest RTA distance to the base plus 
the farthest pss No. 2 distance to the base. In other words, if a pss No. 
2 is located in a town 400 miles from the TspPs base and it is the farthest 
remote group, then the RTA subsystems served by the same TsPs base 
would have to be within a 600-mile radius of the TsPs base. 
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2.4 Hardware technology employed for RTA/ PSS No. 2 


The rTA/Pss No. 2 control circuitry design was one of the early Bell 
System applications of the Transistor-Transistor-Logic (TTL) inte- 
grated circuit technology. The Position and Trunk Control frame, at 
the remote end of the PCL, also consists of scanning circuitry using 
opto-isolators and diagnostic circuitry using instructions stored on 
existing state-of-the-art read-only-memory (ROM) devices. 

The 100C positions provided with pss No. 2 were the first large 
volume application of the 7-segment light-emitting diode (LED) nu- 
meric display. This new display technology was also made available 
for retrofit into the 100B position provided with pss No. 1. 

The rTA/Pss No. 2 features greatly extended the transmission range 
of Tsps. To permit such great distances between operators and cus- 
tomers and still maintain good voice quality required the simultaneous 
development of three key pieces of equipment: the Unified Telephone 
Circuit (4251 B network), the 1P precision hybrid, and a new three- 
way/four-wire bridging repeater. Each of these is discussed in Ref. 3. 

The Logic Analyzer for Maintenance Planning (LAMP) was used 
extensively for the generation of circuit-board test-vector information 
provided to Western Electric. Results were also used to modify board 
designs to improve test access. 

A minicomputer-controlled fault insertion system was developed to 
automate the large and repetitive task of physical fault insertion for 
Trouble Locating Manual (TLM) diagnostic data generation. This new 
system also made available timely feedback to the diagnostic designers 
about potential problems with diagnostic coverage and resolution. 


iil. RTA SUPPORTING FEATURES 


The addition of the RTA feature, expansion of the geographical area 
served by a TSPS, and the necessity for handling special operator 
service traffic, affected several Tsps design parameters and required 
the addition of several new features. For example, with rT«A, the 
maximum number of states and Numbering Plan Areas (NPAS) served 
by TSPS were increased from three to eight. In addition, the maximum 
number of toll switching offices with unique routing patterns serving 
a TSPS complex was increased from three to eight. When advancing a 
call to the toll network, TsPs must sometimes change the dialed or 
keyed digits according to a set of code conversion rules. These rules 
had to be changed to permit the advancement of incoming, inward, 
and INWarts calls through TspPs or RTA toll offices located in more than 
one NPA. 

As mentioned in Section I, as TSPS service is extended to a wider 
area and TSPs capabilities are broadened to handle a wider range of 
call types, cordboard operations which remain solely to handle Special 
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Operator Services Traffic (sostT) become less and less efficient. This 
creates an impetus to handle more of the sost traffic on TSPs, with the 
ultimate aim of eliminating the cordboard operation. Among the SOST 
items that were handled on cordboards, but can now be handled by 
TSPS, are: inward traffic and postpay coin service. In addition, small 
central offices connecting to TSPS require compatible trunk equipment. 
Multiwink coin signaling, an economically attractive method to provide 
coin signaling to these small offices, was also provided in TSPS/RTA. 
3.1 Inward 

Inward calls occur when an operator at the originating end of a call 
requires the assistance of an operator atthe terminating end (called 
the inward operator) so that the latter may perform certain functions 
that the former cannot. 

Examples of inward calls and the functions traditionally performed 
by the inward operator are: 

(t) Verification—the inward operator verifies that a line is busy. 

(iz) Calling hard to reach numbers—the inward operator tries an- 
other route for the call where previous attempts have been unsuccess- 
ful. 

(iii) Call-back to coin stations—the call rating, computing, and 
recording functions are performed by the inward operator. 

(tv) Call back (to a noncoin station) with time and charges (T&c)— 
the inward operator performs call rating, computing, and recording 
functions, and gives the T&c quote to the called party (who originally 
initiated the call). 

(v) Call back to hotel—the inward operator performs call rating, 
computing and recording functions, including identification of the 
hotel guest, and provides the quote of charges to the hotel. 

The inward feature allows a TSPS operator to act as the inward 
operator on an inward call. Figure 5 shows how inward calls are routed 
to a TSPS operator acting as the inward operator. To reach an inward 
operator, the originating operator, whether at a cordboard or at a TSPS 
position, would key forward (NPA)+(TTC)+0c, where NPA+TTC is the 
routine code to the Terminating Toll Center (obtained from a routing 
guide as a function of the NPA+NxXx portion of the number to be 
reached by the inward operator). The numbers in parentheses (i.e., 
(NPA)+(TTC)) are not always present, their presence or absence being 
determined by the route of the call. The abbreviation oc, which stands 
for Operator Code, is a 3- to 5-digit number which specifies the nature 
of the service required from the inward operator. The Operator Codes 
used, together with their associated call types, are shown in Table I. 

The Terminating Toll Center (TTC) recognizes inward traffic from 
the operator code which it receives, i.e., the oc keyed by the originating 
operator. Once it recognizes an inward call, the TTc will seize an inward 
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Fig. 5—Routing of inward calls to TSPS INOP and to the called party. 


Table I—Operator codes and associated inward 
call types [originating operator keys 
(NPA)+(TTC)+ Operator Code (0c)] 





Operator 
Code Inward Call Type 
121 General inward, hard-to-reach, verification 


1150(1)* Collect or call-back to coin 
1155(1)* Time & charges (T&C) call back 
1156(1)* Hotel call back 


* Additional 1 is local practice option. 


trunk to the TSPs serving its toll traffic, and will outpulse the oc to 
that Tsps. From the oc, the Tsps determines the initial display to be 
given to the inward operator. The actions taken by the TSPs operator 


upon arrival of an inward call at the console will depend upon the 
nature of the inward call. 

Inward trunks can be installed at RTAs as well as at a base unit. In 
either case, as shown in Fig 5, the inward trunk connects on its 
incoming side to a toll office outgoing trunk, and on its outgoing side 
to a toll office incoming trunk. The facilities on both sides of the 
inward trunk are classified as intertoll facilities for transmission pur- 
poses. Both base Tsps and RTA inward trunks are four-wire and are 
used with a three-way, four-wire bridging repeater. E&M signaling is 
used on the incoming side. The outgoing side can be arranged for 
either loop or E&M signaling. 

Inward trunks may be organized in one trunk group for every toll 
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office serving the TSPS complex (base unit and RTAs). A single trunk 
group carrying all inward traffic routed to the TsPs or RTA through a 
given toll office will optimize the trunk efficiency. Alternatively, having 
separate trunk groups for each toll office serving the TsPS complex 
optimizes the grade of transmission on inward calls. Most desirable is 
the centralization of inward trunks at the highest class toll switch 
(usually the one serving the base unit) in the TSPS/RTA complex. This 
provides both good trunk efficiency and the ability to meet or exceed 
transmission performance objectives. 


3.2 Postpay coin service 


In postpay coin operation, the coin stations do not have coin collect 
and return functions. Once a coin is deposited, it is not retrievable. 
Therefore, collect and return signals are ineffective and are not used 
in postpay coin operation. Thus the trunks carrying this traffic from 
local offices to cordboards are simpler than those used in prepay coin 
operation. 

Since the operator cannot return coins on a postpay coin call, a 
deposit for the initial period is not requested until: 

(t) The called party answers and 

(tt) It is determined that the correct called number has been 
reached. 

For collection of overtime charges, there is no difference between 
postpay and prepay coin operation except that incorrect or question- 
able deposits cannot be returned. 

Any of three methods may be used to bring postpay coin traffic into 
TsPs from a local office. Under normal conditions (no ANI failure), the 
first two methods result in automatic identification of postpay coin 
calls. The third method requires operator intervention to recognize 
such calls. The three methods are as follows: 

(i) Dedicated Postpay Coin Trunks—The only calls routed to TSPs 
on such trunks are postpay coin calls. 

(ii) Combined Postpay Coin-Noncoin Trunks with ANI Screening 
Identification—This technique is used to identify the kind of call when 
the local office has ANI. The technique consists of searching the coin 
band tables in Tsps for the received ANI number to determine whether 
or not that number corresponds to a coin station. 

(iti) Combined Postpay Coin-Noncoin Trunks with Service Tone 
Identification—For such trunks, the TsPs operator can identify postpay 
coin calls by the presence of a service tone generated by the local 
office. The tone is heard shortly after the zip tone when the call is first 
brought the position. Absence of the service tone signifies a noncoin 
call. 
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3.3 Multiwink coin signaling 


The Bell System Coin Service Improvement Committee recom- 
mended that multiwink signaling coin control be made available to 
provide additional coin control signals. With TsPs-RTA, BR trunk con- 
nections to coin control circuits can be eliminated with multiwink 
signaling, and multiwink is more economically provided than inband 
coin control for certain local offices. 

The multiwink signaling format employs a series of one to five 
supervisory on-hook winks from Tsps to the local office outgoing 
trunks. The signals and their use are shown in Table II. 


IV. ADDITIONAL TSPS FEATURES ON THE RTA GENERIC 


In parallel with the RTA development, other service and maintenance 
features were developed. These features were made available with 
RTA. This section briefly describes those additional features. 


4.1 Selective call screening 


TSPS is required to provide for selective screening of incoming traffic 
that was previously handled by cord switchboards. The ability of TsPs 
to screen calls from various incoming trunks enables the telephone 
companies to offer institutions and businesses (e.g., hospitals, military 
installations, press and media, prisons, and university dormitories) the 
option of restricting the type of charging permitted for toll calls 
originating over some or all of their lines. Some hospitals, for example, 
do not want to expend the administrative effort required to collect 
telephone charges for toll calls from hospital patients. Hospitals could 
receive this kind of service from cord switchboard operators since the 
trunk appearance on the cordboard was labeled as hospital and the 
operator responded accordingly. Given the new ability for Tsps to 
restrict the kinds of charges allowed, the use of coinless public tele- 
phones is also made possible. Coinless public telephones can only be 
used to place credit card, collect, and bill-to-third-number calls. Coin- 


Table ll—Multiwink signaling 
system 
Number 
of 
On-Hook 
Winks Function 
1 Operator release 
2 Operator attached 
3 Coin collect 
4 Coin return 
5 Ringback 
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less public telephones are especially attractive to operating companies’ 
in places such as major transportation centers to reduce the number 
of expensive coin stations. 

Another feature provided with screening is the charge quotation 
feature. It allows businesses (such as law firms) to get voice or 
automatic quotation of telephone charges on calls by account numbers 
similar to the Tsps hotel/motel feature. 

TSPs performs the following basic functions in handling a screened 
call: 

(t) TSPS determines if the line is a screened line. This is done with 
information present in the trunk software register indicating the 
trunk group as screened or by the presence of that line number in 
screening line number tables. 
(ut) If the line is screened, TSPs identifies what type of screening is 
applicable. A table, called the screening type table, indicates the 
specific combinations of restrictions allowable. Each line number in 
the screening line number table has an index to the applicable 
combination of restrictions in the screening type table. 
(tit) TSPS also validates the operator’s actions. Since the screening 
restrictions are in memory, the acceptability of the class of billing 
entered by the operator is checked. If the operator enters an unac- 
ceptable class of charge, the system informs the operator by flashing 
the appropriate key/lamp. The operator then interacts with the 
customer in an effort to obtain acceptable billing. 

(tv) Once an acceptable class of charge is entered, a unique mark is 

placed on the Automatic Message Accounting (AMA) tape indicating 

that the call was a screened call. 

Any of three methods may be used to bring screened traffic into 
TSPS from a local office: 

(1) Mixed traffic (combined screen/nonscreen). 

(ii) Dedicated screened traffic. 

(tii) ANI 7 information-digit-identified screened traffic. 

In the mixed traffic case, traffic with screening conditions and traffic 
without screening conditions will originate over the same trunks. A 
search is conducted using the calling digits provided by Automatic 
Number Identification equipment (ANI) to determine if a screening 
condition exists on that particular line. If the calling number is not in 
the search tables, it is assumed that the line does not have a screening 
condition on it. If an ANI failure occurs, Operator Number Identified 
(ONI) digits are used for the search. 

In the dedicated traffic case, a trunk group is dedicated to screened 
traffic. If local offices without ANI require screening, dedicated trunks 
must be used to deter fraud. If the trunk belongs to the dedicated 
screening trunk group, the calling number obtained by the operator is 
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checked against the screening line number tables, as in the mixed 
traffic case, to determine the specific restrictions. 

In the case of calls from an electronic local office, an ANI 7 infor- 
mation digit is supplied for screened calls. The ANI information digit 
is denoted I in the following ANI sequence: 


KP-I-7D-ST, where 7D is the 7-digit calling number. 


If the ANI information digit or any part of the ANI sequence is 
destroyed or not received at TSPS, ONI digits are obtained and a search 
conducted as in the mixed traffic case. Given good ANI, the calling 
number is then checked against the line number table to determine 
the specific restrictions. 


4.2 More stores/ bus (MORSTR) 


More stores/bus (MORSTR) is an all-software feature which expands 
the Stored Program Control (spc) No. 1A store maintenance structure 
to cover all expected piggyback twistor/semiconductor memory con- 
figurations. It removes the memory capacity limitation imposed by the 
previous maintenance software (20 stores/bus). 

The maximum capacity of the sPc memory was limited by the 
maintenance software and by processor addressability. It was esti- 
mated that the larger Tsps systems with a combination piggyback 
twistor (PBT) and semiconductor memory stores would exceed the - 
memory capacity limitation imposed by the maintenance software (20 
stores/bus) upon advance to subsequent generics. The MORSTR feature 
was developed to provide maintenance capabilities for a maximum of 
24 stores/bus. The spc store maintenance software with MORSTR can 
support the various PBT/semiconductor memory combinations up to 
a limit imposed by the processor with the restriction that no more than 
18 of the maximum 24 stores can be of the PBT type. 


V. RTA CHARACTERISTICS REQUIRING SPECIAL DEVELOPMENT 
EMPHASIS 


5.1 Necessity for more stringent transmission requirements 


The original Tsps base system served by the Position Subsystem 
(pss) No. 1 presented a transmission environment confined and sim- 
plified by the T1 carrier. The T1 carrier transmission limit meant that 
remote Pss No. 1 locations were relatively close to the toll office. With 
the introduction of RTA and Pss No. 2, a complex set of transmission 
considerations arose due to the large range of subsystem site locations 
allowed by the peripheral control link design. The Tsps transmission 
plan was revised to provide engineering and maintenance documen- 
tation for TSPS in the new RTA/Pss No. 2 environment. 
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5.2 Maintenance of unattended remote offices 


The design intent for the RTA/Pss No. 2 feature is to provide for the 
primary maintenance of RTA and Pss No. 2 subsystems by a craftsforce 
situated at the base TspPs location. Upon identification of a fault in the 
remote equipment, remote site personnel would then be dispatched to 
replace or repair the faulty equipment. This requirement to provide 
base-located maintenance control reflects the general trend to more 
centralized maintenance in the Bell System. 

Maintenance software design for the RTA/PSS No. 2 feature was 
strongly influenced by this trend. It was complicated by the need to 
provide also for those operating company situations in which more 
direct maintenance control was to be exercised by craftspeople situated 
at the remote locations. 

The normal maintenance strategy associated with such items as 
teletypewriter interactions and visual status displays takes on an added 
dimension of difficulty when complicated by the introduction of mul- 
tiple distant equipment sites. 

More detail about the maintenance strategy chosen is provided in a 
subsequent article in Ref. 1. 


5.3 Rapid RTA/ PSS No. 2 installation buildup 


The rTA and pss No. 2 features are very attractive to operating 
telephone company planners because of the much increased flexibility 
for operator team location, the economic and service gains achieved 
with the replacement of small toll office cordboards, and the ability to 
prove in new TSPS base offices for cities of moderate size. The early 
demand was high, and the resulting pressures on Western Electric to 
supply that market were evident in the final stages of development 
and deployment. 

Due to the efforts of many departments involved with manufacture, 
testing, documentation, installation, and support at the Western Elec- 
tric, Columbus works and the regional offices, that heavy initial de- 
mand was satisfied. One year after the initial RTA and pss No. 2 cutover 
at Utica, New York, on May 16, 1976, a dozen peripheral control links 
were in service and nearly one hundred had been shipped to the field. 
By year-end 1978, 120 RTA subsystems and 60 pss No. 2 groups had 
been placed into service. 
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Transmission and signaling implications are important for the 
successful introduction of the Remote Trunk Arrangement (RTA) and 
the Position Subsystem (pss) No. 2 features into the Traffic Service 
Position System (TSPs), since both features involve the possibility of 
substantial distances between the TsPs operators and the customers. 
Consequently, a new transmission plan including objectives for in- 
serted connection loss (IcL), received noise, balance, and operator 
sidetone was established and some new transmission equipment was 
provided. The overall objectives, general and specific considerations, 
maintenance facilities, signaling implications, and new transmission 
equipment are described. Emphasis is placed on those aspects that 
are novel or newly introduced as the result of RTA and Pss No. 2. 


1. OVERVIEW 


An RTA or Pss No. 2 being located at a remote site several hundred 
miles distant from the base TSPsS presents an entirely new set of 
transmission and signaling implications. First, there is the peripheral 
control link or PcL, which extends the control capability of the TsPps 
processors to the remote locations. Then there are transmission con- 
siderations within the RTA and pss No. 2, modifications required to 
pss No. 1, the introduction of new transmission equipment, signaling 
ramifications, and finally the need for additional impedance balancing. 


1.1 The peripheral control link (PCL) 
Figure 1 shows the pci which includes, among other components, 
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Fig. 1—Peripheral control link. 


three data lines used to transmit and receive information to and from 
the remote sites. System requirements dictate that any standard 
intertoll grade transmission facilities may be used for all circuits 
between the base and the RTA or PSS No. 2. Hence, the data transmis- 
sion circuits must also meet that constraint. Accordingly, the PCL 
employs 2400 baud modems with the data lines treated as uncondi- 
tioned, 4-wire private line circuits. This moderate data rate coupled 
with distances of up to several hundred miles between modems re- 
quires that the round-trip delay time required to transmit an instruc- 
tion to a remote site and receive back an acknowledgment must be 
limited and must be considered in the design of the data lines. 

For reliability, another system requirement specifies that the trans- 
mission facilities between base and remote follow at least two diverse 
routes with one of the two primary data lines in each route. Since, 
under normal operation, data received on these lines are compared or 
“matched,” a limit must also be placed on the delay differential; that 
is, on the difference between the delay times of the two routes. Both 
the delay differential and the round-trip delay times cannot be so 
restrictive, however, that they substantially restrict the choice of 
alternate routes between the base and the remote units or severely 
limit the length of the voice transmission facilities. 


1.2 The remote trunk arrangement (RTA) 


At the RTA, connection to a TSPS operator is made by bridging onto 
the toll connecting trunks (TCTs) in a manner similar to that employed 
at the base. This is shown in Fig. 2. Bridging 900-ohm, 2-wire trunks 
is accomplished by a simple tap that presents a 450-ohm impedance 
(two 900-ohm terminations in parallel) to the RTA network (concentra- 
tor). Bridging 4-wire trunks requires an associated 3-way, 4-wire bridg- 
ing repeater which converts the 4-wire bridged tap to 2-wire and which 
also presents a nominal impedance of 450 ohms to the concentrator. 
Conversion of 4-wire circuits to 2-wire is always required, since both 
the RTA and the base TsPs switching networks (RTA concentrator and 
TSPs trunk and position link circuits) are 2-wire. 

The RTA concentrator connects the bridged TcT to a base-remote 
(BR) trunk, typically a 4-wire intertoll grade facility up to several 
hundred miles long. Two-wire to 4-wire conversion at both ends of the 
BR trunk is accomplished by 24V4-type repeaters using a 900-ohm, 4- 
wire terminating set (4wTs) at the base and a high-impedance 4wTs at 
the RTA. Finally, the connection is completed through the base network 
to an operator’s position, either a PSS No. 1 or a pss No. 2. 

If the performance of this connection as a function of the length of 
the BR and operator position trunks is examined, two types of trans- 
mission degradation are encountered. The first is echo, as detected by 
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Fig. 2—rsps No. 1—voice transmission configuration. 


the customer(s) and the operator, due to the impedance mismatch at 
the extra switching point introduced at the RTA concentrator and 
accentuated by the long BR (and operator position) trunks. As dis- 
cussed later, echo is controlled through impedance balancing and by 
a new operator’s telephone circuit. The second form of transmission 
degradation is noise introduced by the long facilities and controlled by 
the use of compandors on analog facilities or by the use of digital 
facilities. 


1.3 The position subsystem (PSS) No. 2 


pss No. 2 was devised to eliminate the constraints of the original 
position arrangement (pss No. 1), which uses unique DIC channel 
banks and T1 carrier as the transmission facilities for remote instal- 
lations, and thus is limited in range to approximately 80 miles. Con- 
versely, PSS No. 2 may use any toll grade carrier system and is limited 
in range only by the noise introduced by the transmission facilities. 
Hence, received noise is the limiting parameter in the permissible 
distance between operators and RTAs when standard message grade 
circuits are used. 

The 4-wire operator trunk circuits are connected to the TSPs switch- 
ing network via 24V4 repeaters and high-impedance 4wTs in the same 
way as BR trunks at the RTA concentrator. This arrangement permits 
the pss No. 2 circuits to be connected to the bridged base TcTs or to 
BR trunks. At each operator’s position, new 4-wire telephone networks 
provide adjustable sidetone, automatic gain control (AGC), and a voice 
switched attenuator (VSA). 


1.4 The position subsystem (PSS) No. 1 


It is necessary and desirable to add RTAs to existing TSPSs which 
have the original position subsystem arrangements, now designated 
pss No. 1. This arrangement employs the equivalent of an unbalanced 
4wtTs at the base unit end of the position trunks to return a fixed 
portion of the operator’s transmitted signal which serves as sidetone 
to the operator. No vSsa or sidetone adjustment is provided. When an 
RTA is added, however, the possibility of additional echo from the 
connection at the RTA makes this an unsuitable arrangement. Hence, 
the pss No. 1 unbalanced 4wrts is replaced with a precision balanced 
Awrts, and the position is equipped with the same telephone network 
used in the pss No. 2. No changes are required in the pss No. 1 when 
only pss No. 2 is added to an existing system. 


1.5 Transmission balance 


With the introduction of RTA and pss No. 2, the geographical extent 
of a single TSPS was transformed from a rather confined area around 
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a toll office to a system that might cover complete states or even larger 
areas. Under these circumstances, the distance a call must travel to 
the operator access point in the network may be significant compared 
to the length of the average customer-to-customer connection. In those 
cases, it becomes necessary to treat the operator connection as a toll 
facility. Toll facilities are characterized by trunks and switching net- 
works which are low loss and transmission balanced and, indeed, these 
are exactly the requirements that have been introduced into TSPs. 
Transmission “balance” means matching impedances at all 2-wire to 
4-wire junctions to maintain a loss design that allows accurate sum- 
mation of the losses of the parts while at the same time preventing 
unwanted signal reflections or “echos” from mismatched junctions. 

In the past, balance was not required for TSPS equipped with Pss 
No. 1 positions, and such systems still do not require balancing. 
However, whenever a TSPS is equipped with an RTA or is equipped with 
a pss No. 2 in which the operator trunks exceed 200 miles in length, 
the entire system must be balanced. 

To facilitate balancing, adjustable network build-out capacitors 
(NBOCs) are provided by all the 4wTss or equivalent used in the system. 
Drop build-out capacitors (DBOCs) are provided or specified at the 2- 
wire line (or drop) anywhere there is a 4-wire/2-wire transformation 
on the trunk-link side of the Tsps network. 


1.6 Inward trunks 


With the introduction of Tsps Generic Program 7, TSPS base units 
and RTAs have the capability of performing some traditional inward 
operator functions such as general assistance, time and charges, call- 
back, and hotel call-back. A special 4-wire inward trunk must be used 
to handle inward calls. This inward trunk is composed of a toll office 
outgoing trunk circuit, a TSps 4-wire bridging arrangement to provide 
TSPS operator access to the inward trunk, and a toll office incoming 
trunk circuit. These three circuits are interconnected by 4-wire facili- 
ties. An incoming call is switched by the toll office to the outgoing 
trunk circuit associated with an inward trunk and a TSPs operator is 
added to the inward trunk through the TsPs or RTA switching network. 
After the appropriate actions are performed by the operator, the toll 
office incoming trunk circuit associated with the inward trunk is 
switched by the toll office to the appropriate toll switching trunk, 
thereby extending the inward call to the desired end office. The inward 
trunk remains in the connection between the calling and called cus- 
tomers after the operator has released from the connection. 


1.7 New equipment 


Several new pieces of transmission-related equipment were intro- 
duced as a consequence of RTA and pss No. 2. 
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A new unified operator’s telephone circuit, or UTC, was designed to 
provide several improvements such as dual headset operation and 
supervisor conferencing without transmission degradation. The uTc 
also provides a voice-switched attenuator (VSA) to control operator 
talker echo return, an automatic gain control (AGc) circuit to protect 
the operator from high-level signals, and independent sidetone adjust- 
ment to permit meeting sidetone level objectives. Gain and line equal- 
ization adjustments are supplied to permit the uTc to properly termi- 
nate any standard transmission facility. 

To eliminate unwanted echo at the point where BR or operator 
position trunks are bridged onto a TCT, a new precision-balanced 
hybrid, the type 1P 4-wire terminating set was introduced. This hybrid 
is characterized by a high-impedance 2-wire port (approximately 11,600 
ohms) and a very high trans-hybrid loss. 

Two new 3-way, 4-wire bridging repeaters were also introduced to 
substantially improve transmission quality when bridging 4-wire cir- 
cuits. The previous bridging arrangements produced a volume contrast 
to both the customers and the operator between calls on 2-wire and 
calls on 4-wire TCTs, with the 4-wire circuits exhibiting approximately 
3 to 6.5 dB greater loss, depending on the direction of transmission. 
The new bridges eliminate this problem and permit gain adjustment 
in every direction from the bridging point. 


1.8 Signaling considerations 


Like the base Tsps, the RTA is required to transmit and receive 
various types of signals. Among these are address signals (i.e., the 
called and calling numbers), coin control signals, ringback signals, and 
ringforward signals. The rTA trunk circuits allow each signal to be 
transmitted in at least two different ways. Unlike the base unit trunks, 
however, the RTA trunks are not required to generate +130 V dc signals 
for coin control and ringback. 

The RTA must be able to receive address signals either as dial pulses 
or multifrequency (MF) tones from originating local offices but is 
required to forward address information to the toll office only in MF 
form. Coin control and ringback signals toward the originating office 
can be either inband (MF tones) or multiple wink (mw), which consists 
of a specified number of timed on-hook/off-hook dc “winks.” Ringfor- 
ward signals may be either +130 V simplex or a single “wink.” 

In TSPS/RTA, as in other systems not equipped with common channel 
interoffice signaling (ccis), the signals described above must be trans- 
mitted over virtually the same paths used for voice transmission. 
These paths include the BR trunks between the base and the RTA since 
all the common signaling circuits (e.g., MF receivers, MF outpulsers, 
coin control and ringback circuits) are located at the base. Hence, care 
must be exercised when engineering the transmission paths to ensure 


RTA TRANSMISSION AND SIGNALING 1143 


that signaling is properly considered. Transmission level points (TLPs) 
‘ must be carefully controlled to guarantee correct processing of MF 
signals by the various switching offices involved. MF signaling specifi- 
cations call for —7dBm per tone signal power at 0- TLP (i.e., —7dBm0). 
Changes are being incorporated into Tsps to comply with this specifi- 
cation. 


ll. OBJECTIVES AND GENERAL CONSIDERATIONS 


2.1 Voice transmission objectives 


A standard TSPS/RTA connection is a 3-party call among the calling 
customer, the called customer, and the TspPs operator (see Fig. 3). This 
standard connection was considered to be the same as three 2-way 
connections, each of which must meet its own transmission objectives. 

The transmission objective set for the 2-way customer-to-customer 
connection is to provide loss-noise-echo performance, which is the 
same as that of regular direct distance dialed (DDD) toll calls that do 
not have TSPS access but have the same length. This objective applies 
whether or not the operator is in the connection and has two corollar- 
ies, namely: (z) the toll connecting trunk (TCT) satisfies the standard 
DDD network transmission requirements in both the 2-way and 3-way 
connection, and (ii) the performance provided on calls handled by 
TSPS is the same as calls handled by the ppp network. 

The transmission objective placed on the 2-way operator-to-calling- 
customer connection was that it have loss-noise-echo performance 
equivalent to that provided on an average short DDD toll call between 
100 and 150 miles in length. This objective is satisfied by the TSPS/RTA 
transmission design even when there are several hundred miles be- 
tween the operator position and the TsPs access point on the incoming 
trunks to the toll office. This performance is obtained because (1) the 
TSPS access point was given the same transmission level as the toll 
office incoming trunk which reduces the level contrast at the operator 
position between the received volume from the calling customer and 
that from the called customer, (ii) the BR trunk has zero loss to 
minimize volume contrast observed by the operator between calls 
accessed at the base unit and those accessed at an RTA, (li) circuit 
noise on the trunk facilities was limited, and (iv) impedance balance 
was provided for all trunks to avoid echoes. 

Similarly, the transmission objective for the 2-way operator-to-called 
customer connection was that its loss-noise-echo performance be ap- 
proximately the same as that of the connection between calling cus- 
tomer and called customer. Two potential transmission degradations 
that had to be considered in meeting this objective were (1) customer 
and operator talker echoes as a result of the extra 2-wire switching 
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Fig. 3—Connection model of a typical call handled through TsPs via RTA. 


point at the RTA and the long BR and operator position trunks, and (it) 
high noise levels in long BR and operator trunk facilities. 

Transmission objectives were also imposed on operator sidetone and 
trunk facility noise. The operator sidetone objective was made the 
same as that used for subscribers, namely, an acoustical sidetone path 
loss of 12 + 4 dB. Noise objectives on all Tsps associated trunks were 
made the same as those for the DppD network trunks which use intertoll 
grade carrier facilities. 


2.2 Deviations from requirements 


Deviations from transmission requirements were constrained be- 
cause the sum of many small deviations would cause large overall loss 
variations between connections. Some loss considerations were: 

(t) Zero loss was required between the toll office and the base unit 
or RTA access points on toll connecting and inward trunks. Because 
any variation in this loss changes the effective TSPS access point on 
these trunks and, consequently, increases the speech volume from one 
customer and decreases it from the other, a permissible maximum 
variation of only 0.5 dB was set. For 2-wire trunks and 2-wire toll 
switches, the 0 to 0.5 dB loss requirement limits the wiring gauge and 
length that is used between the base unit (or RTA) and its associated 
toll office. Four-wire access trunks were aligned to 0 dB loss without 
difficulty. The permissible loss variation also determined the schedule 
for trunk maintenance and trunk down limits. 

(it) BR trunk loss variations were stipulated to limit the volume 
contrast for calls between operator and customers. The permitted 
variation was made the same as that for intertoll trunks in the ppp 
network. It was recognized that these level changes also affect signaling 
tones since MF outpulsers are only provided at the base unit so that 
the MF signaling tones are transmitted to the RTA over the BR trunks. 

(tii) Loss variations in operator position trunks add to the volume 
contrasts heard by the customers. Such trunks were given same 
standard loss variations as intertoll message trunks. 


2.3 Transmission level points (TLP) 


TSPs conforms to the standard transmission level point (TLP) plan of 
the Bell System, which makes the local class 5 office a 0 TLP for 
outgoing signals. Since the trunk loss and its control are primary 
requirement in TSPS, transmission level points were adjusted as re- 
quired to meet (z) trunk loss requirements, (it) loading objectives for 
carrier facilities, and (iii) standardized toll office transmission level 
points. To do this, the outgoing TLP of the TSPS was adjusted to 
conform with the expected received level on the toll-connecting trunk 
being tested. All trunks internal to the base unit and RTA are considered 
to be at —3 TLP. 
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il. VOICE TRANSMISSION CONSIDERATIONS 


As discussed in Section I, tsps Generic 7 introduced the pss No. 2, 
the RTA, and inward call-handling features. As a consequence, the RTA 
concentrator, which is a new switch, and new types of trunks (i.e., PSS 
No. 2 operator position, BR, and inward trunks) were added to existing 
TSPS base units as shown in Fig. 2. Modifications were also made in 
certain existing base unit circuits to meet the TSPS voice transmission 
objectives discussed in Section II. Each type of trunk associated with 
a base unit equipped with the RTA, pss No. 2, and inward call-handling 
features was designed to satisfy specific transmission requirements to 
meet transmission objectives. These objectives were stated in terms of 
loss-noise-echo performance provided to the customer(s) and to the 
operator on all the possible connections used in Tsps. The loss-noise 
performance provided on a given type of connection was controlled by 
setting requirements on (z) the inserted connection loss (ICL) and (iz) 
the noise which may be introduced by each of the various trunks in 
the connections. The talker echo performance provided on a given 
connection depends upon both the loss and the round-trip signal 
propagation delay of the talker echo signal path. Because the round 
trip propagation delay of the echo path depends markedly on the 
length of a given connection, the loss in the echo path is used to 
control the echo performance provided on a given connection. For 
example, in the UTC described in Section 1.7, the loss of the echo path 
is controlled by introducing additional loss in the receive path when 
the talker speaks but not in the talker’s transmission path. In addition, 
specific balance requirements are satisfied at all junctions between 4- 
wire and 2-wire transmission facilities. These specific transmission 
requirements (i.e., ICL, noise, and balance) are considered in subse- 
quent sections. 

Whenever the RTA feature is added to an existing TSPS base unit 
equipped with the original pss No. 1 operator positions, the operator 
position trunks are modified as follows: 

(t) The existing operator telephone circuits are replaced by the UTC 
with the voice-switched-attenuator (VSA) and automatic gain control 
(AGC) features enabled. 

(tz) For operator positions located remotely from the base units, the 
Dic channel units at the base unit end of the trunk are replaced by a 
new Dic channel unit which incorporates the equivalent of a 1P 4-Wire 
Terminating Set (4wTs). 

(tit) For operator positions located near the base unit, the 1H 4wrTs 
used in the 24V4 repeater at the base unit end of the trunk are replaced 
by the 1P 4wrTs. 

Whenever the RTA feature is added, the service observing circuit 
used in existing TSPS base units is replaced by an improved circuit. 
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Prior to the introduction of Generic 7, a 3-way connection among (1) 
the TSPS operator, (ii) a service assistance operator, and (vit) the 
customer was permitted. However, with the introduction of Generic 7, 
such a 3-way connection is no longer provided because of transmission 
loss and balance problems with the extended range TSPs system. Only 
a 2-way connection is provided between a TSPS operator and a service 
assistance operator, during which the calling customer will be put on 
hold. The circuit modifications outlined above were needed to meet 
the echo performance objectives discussed in Section 2.1. 


3.1 Network arrangements 


Figure 2 is a functional block diagram of the voice transmission 
configuration of the base unit, operator positions, and RTA, and includes 
the various types of trunks. Typical trunking and switching arrange- 
ments at a base unit equipped with the inward call handling, a pss No. 
2, and an RTA are shown in Fig. 4. Figure 5 illustrates the typical 
trunking and switching arrangements for an RTA installation. 

As shown in Fig. 4, the operator position trunks of the pss No. 2 and 
pss No. 1 retrofitted with the utc as well as the service observing 
trunks all have 2-wire appearances on the position link circuit of the 
base unit switching network. These trunks use 4-wire facilities which 
are converted from 4-wire to 2-wire by a bridging hybrid (i.e., a 1P 
4wTs, or equivalent) at the base unit. All the types of trunks shown in 
Fig. 4 that have appearances on the trunk link circuit of the switching 
network can be connected to at least one of the three types of trunks 
having appearances on the position link circuit. All BR trunks use 4- 
wire facilities while operator service trunks and centralized automatic 
message accounting (CAMA) transfer trunks may use either 2-wire or 4- 
wire facilities. When 4-wire facilities are used, a 900-ohm 4wTs (e.g., 
1M 4wtTs) is used to provide the necessary conversion from 4-wire to 
2-wire. All inward trunks, 4-wire TcT, delayed call trunks, and service 
observing trunks use 4-wire facilities with bridging access to these 
trunks provided by 3-way, 4-wire bridging repeaters. The equivalent of 
a 900-ohm 4wTs is incorporated in the bridging repeaters to provide 
the necessary conversion from 4 wire to 2 wire. Two-wire TCTs are 
bridged directly at both the RTA and base unit. This is illustrated 
schematically in Figs. 4 and 5. 

As shown in Fig. 5, all connections through the RTA concentrator 
between a BR trunk and either a TcT or an inward trunk are made on 
a 2-wire basis. All BR trunks at the RTA use 4-wire facilities and a 1P 
4wrts to provide the necessary conversion from 4-wire to 2-wire trans- 
mission. The TcT and inward trunk arrangements are essentially the 
same as that described above for the base unit. 
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Fig. 5—rva trunks and switching arrangements. To simplify the sketch, the T2 port connection to the RTA concentrator is not shown. 


3.2 Inserted connection loss (ICL) 


The ICL requirements on each of the various types of TSPs trunks 
shown in Fig. 2 are summarized in Table I. It should be noted that the 
introduction of Generic 7 has not affected the ICL requirements on 
those trunks which existed before its introduction. The ICL require- 
ments on the new trunks introduced with Generic 7 are discussed next. 

The IcL requirements must be the same for TCTs accessed by either 
a base unit or an RTA as for TCTs not accessed by TSPS to avoid any 
contrast in transmission performance provided to the customers be- 
tween directly dialed calls and operator-assisted calls. One additional 
ICL requirement peculiar to TcTs provided with either base unit or RTA 
access is that the portion of the TcT between the TspPs bridging point 
and the outgoing side of the toll office switch should nominally be 
0 dB with a maximum of 0.5 dB. This IcL requirement applies for both 
voice signals and MF signals and is needed (z) to equalize the transmis- 
sion loss between the TSPs operator and the calling customer and 
between the operator and the called customer to minimize received 
speech volume contrast and (ii) to provide MF address signals to the 
toll office at the standard signaling power levels. 

The Ic for the Br trunks is 0 dB. Since any TSPs operator can be 
called upon to service calls switched through either the base unit or an 
RTA, this requirement assures that there will be no significant volume 
contrast between such calls. It also ensures that the voice frequency 
MF signals generated at the base unit will reach the TcT bridging point 
at the standard power level. 

The inward trunks introduced with Generic 7 may be considered as 
two secondary intertoll trunks in tandem, that is: (1) a secondary 
intertoll trunk from the toll office incoming to the base unit (or RTA) 


Table |—Inserted connection loss requirements for TSPS trunks 


Type of Trunk IcL (dB) 
1. Toll connecting trunk between tsps No. 1 incoming trunk circuit at 0, max. 0.5 


the Tsps base unit or RTA and the toll office 
2. pss No. 2 operator position trunk 
a. Operator transmit direction 
b. Operator receive direction 
3. Retrofitted pss No. 1 operator position trunk 
a. Operator transmit direction 
b. Operator receive direction 


oon won 


4. Base-remote trunk 

5. Inward trunk between Tsps No. 1 inward trunk circuit at the TsPs 0, max. 0.5 
base unit or RTA and the toll office 

6. Delayed call trunk between Tsps No. | delayed call trunk circuit 0, max. 0.5 
and toll office 

7. CAMA transfer trunk 
a. Voice path 0, max. 0.5 
b. MF signaling path 0, max. 0.5 

. Operator service trunk 0, max. 0.5 


<o CO 


. Service observing trunk 
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for connection to an operator, and (ti) a secondary intertoll trunk from 
the base unit (or RTA) back to the toll office for connection to the 
desired end office. As such, each of these two sections of an inward 
trunk is composed of 4-wire facilities having an IcL of 0 dB nominal, 
with a maximum of 0.5 dB. 

The ict for the pss No. 2 operator position trunks and for the 
retrofitted pss No. 1 operator position trunks is the same. The Icu for 
both types of operator trunks depends on the direction of transmission. 
An Ici of 7 dB is used for the operator transmit direction so that the 
average speech power level from the Tsps operators delivered to the 
bridging point on the TcTs will be nominally equal to the average 
speech power level from the calling customers arriving at the same 
point. An 1CcL of 9 dB is used for the operator receive direction so that 
the preferred average speech power will be delivered to the operator 
when a customer’s average speech level is applied to the bridging point 
on a TCT. 


3.3 Noise 


The maximum circuit noise permitted on all the various types of 
TSPs trunks existing before the introduction of Generic 7 was the same 
as on corresponding type trunks in the message network. This made it 
possible to use standard toll grade carrier arrangements in the makeup 
of the facilities for Tsps trunks whenever necessary. The noise limits 
on those trunks remain unchanged by the introduction of Generic 7 
features, with the possible exception of the CAMA transfer trunks, 
which are discussed later. However, some special noise requirements 
for the inward, BR, and pss No. 2 operator position trunks are intro- 
duced with Generic 7. 

In the event that an inward call is extended to the desired called 
customer, the inward trunk remains in the overall connection between 
the calling and called customers after the operator releases from the 
connection. As discussed in Section 3.2, an inward trunk may be 
considered as two secondary intertoll trunks in tandem interconnected 
via a 3-way, 4-wire bridging repeater. To limit any degradation in the 
quality of the loss-noise performance provided to the calling and called 
customers, each of the two portions of the inward trunk are composed 
of low-noise 4-wire facilities such as intertoll grade T-carrier and/or 4- 
wire metallic facilities. 

Any type or combination of types of intertoll grade voice facilities 
may be used in the makeup of a pss No. 2 operator position trunks or 
BR trunks. The amount of noise introduced by the facilities is limited 
for loss-noise performance reasons. The loss-noise performance pro- 
vided on customer/operator connections is adversely affected by the 
additional circuit noise introduced by long pss No. 2 operator position 
trunks and long BR trunks. 
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If a pss No. 2 is provided at a given TSPs base unit, but not an RTA, 
the loss-noise performance objective is met on customer/operator 
connections if the facility route length of analog carrier facilities used 
in any operator position trunk is no greater than 400 miles. This length 
limitation applies if the following noise maintenance limits are ob- 
served on the analog carrier facilities used in the operator position 
trunk: 





Analog Remove From Maintenance 
Carrier Length Service Limit Req’d Limit 
(route miles) (dBrnC0) (dBrnC0) 
0- 50 40 32 
51-100 40 33 
101-200 40 35 

>200 44 37 


If companded L-multiplex analog carrier facilities are used in the 
operator position trunk, the maximum facility route length may be 
extended to 1000 miles. It should be noted that the length of a single 
intertoll grade digital carrier facility (e.g., T-carrier) when used in 
tandem with an analog carrier facility can be ignored when applying 
these length restrictions. If the RTA feature is provided but not the pss 
No. 2 feature, the above discussion on the makeup of Pss No. 2 
operator position trunk facilities applies directly to BR trunks. If both 
the pss No. 2 and RTA features are provided at a given TSPS base unit, 
the analog carrier facility length restrictions indicated above must be 
apportioned between the operator position trunks and the BR trunks. 
The length restrictions, of course, apply to all the diverse routes taken 
by the BR and operator trunks. 

The introduction of RTA increases the likelihood that some of the 
CAMA transfer trunks to a given base unit will be long. The CAMA 
traffic, formerly handled by operators located near a toll office which 
is now being served by an RTA, will now most likely be routed over 
CAMA transfer trunks to the base unit for handling by TsPs operators. 
This, coupled with the possibility that. the base unit may also be 
equipped with a remote Pss No. 2, places more stringent noise require- 
ments on the CAMA transfer trunks so that their maximum circuit 
noise is now the same as for the BR trunks discussed above. 


3.4 Transmission balance 


RTA and pss No. 2 add a new 2-wire switching point (RTA concentra- 
tor) and long lengths of facilities to the overall connection between the 
customers and the TSPs operator. As discussed in Section 1.5, the extra 
switching point introduced another potential source of talker echo 
whenever the trunks to be switched use 4-wire facilities. The long 
lengths of facilities increase the round-trip propagation delay of any 


RTA TRANSMISSION AND SIGNALING 1153 


talker echo signal already existing which makes that echo more dis- 
turbing to the talker. To meet echo performance objectives on connec- 
tions involving TsPs operators, balance requirements must now be 
placed on the various connections through the base unit and/or 
through the RTA when at least one of the trunks involved in the 
connection uses 4-wire facilities. Balance refers to matching circuit 
impedances to control the magnitude of the signal reflected toward 
the source at the junction between 4-wire and 2-wire facilities. 

In general, the termination of a 4-wire facility and its conversion to 
a 2-wire facility is accomplished with a 4wTs, or equivalent. A 4wTs 
contains a balanced hybrid transformer that facilitates the transfer of 
signal power from the 4-wire receive path into the 2-wire facility and 
from the 2-wire facility into the 4-wire transmit path. However, some 
signal power arriving on the 4-wire receive path will be returned on 
the 4-wire transmit path whenever differences exist between the 
impedance of the 2-wire facility and the impedance of the balancing 
network of the 4wts. The degree of balance between these two 
impedances will determine what portion of the signal power will be 
returned to the source. 

The balancing networks used in each of the various types of 4wTss 
(or equivalent) shown in Fig. 4 and 5 consist of a compromise network 
plus an adjustable network build-out capacitor (NBOC), which shunts 
the compromise network. The compromise network is designed to 
provide impedances over the voice frequency band of 200 to 3400 Hz 
that match the nominal impedance of the 2-wire circuits which may 
be connected to that 4wrs. The NBOC is included in the balancing 


Table Il—Balance requirements on the bridging hybrid at the base 
unit end of PSS No. 2 and retrofitted PSS No. 1 operator position 
trunks and the RTA end of base-remote trunks 








Echo Return Singing Return 
Type of Trunk Loss (dB) Loss (dB) 
Connected to TSPS 
Bridging Hybrid Median Minimum Median Minimum 
1. Base unit and RTA 
a. 2-wire toll connecting 15 13 N.S.* 6 
trunk 
b. 4-wire toll connecting N.S. 19 N.S. 15 
trunk 
c. Inward trunk 24 21 19 16 
2. Base unit 
a. Base-remote trunk 24 21 19 16 
b. 4-wire delayed call trunk 24 21 19 16 
c. 4-wire operator service 24 21 19 16 
trunk 
d. 4-wire CAMA | transfer N.S. 21 N.S. 16 
trunk (voice path) 
e. Service observing trunk 24 21 19 16 


* Not specified. 
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Table lIl—Balance requirements on 4WTS, or equivalent, associated 
with various types of 4-wire trunks on connections to a bridging 
hybrid in TsPs base unit or RTA 





Echo Return Singing Return 
Loss (dB) Loss (dB) 
Type of 4-Wire Trunk Median Minimum Median Minimum 
1. Base unit and RTA 
a. Toll connecting trunk N.S.* 26 N.S. 19 
b. Inward trunk N.S 26 N.S. 19 
2. Base unit 
a. Base-remote trunk N.S 26 N.S. 19 
b. Delayed call trunk N.S 26 N.S. 19 
c. Operator service trunk N.S 26 N.S. 19 
d. CAMA transfer — trunk N.S 26 N.S. 19 
(voice path) 
3. Service observing trunk N.S 26 N.S. 19 


* Not specified. 


network to simulate the capacitance of the office cabling included 
between the 2-wire port of the 4wTs and the point of good impedance 
of the connecting circuit, which is defined as a point of fixed nominal 
2-wire impedance. For example, the point of good impedance of a 
trunk using 4-wire facilities is the 2-wire port of a 4wTs. 

The balance requirements on the 1P 4wts (or equivalent) at the 
base unit end of pss No. 2 trunks, retrofitted pss No. 1 trunks and 
service observing trunks, or at the RTA end of BR trunks, vary depend- 
ing upon the type of trunk connected through the base unit network 
or RTA concentrator to the 1P 4wrs. The balance requirements, listed 
in Table II as a function of trunk type, are identical regardless of 
whether the connections are made through the base unit or through 
the RTA. 

The balance requirements on the 4wTs (or equivalent) associated 
with the various types of 4-wire trunks which can be connected through 
the base unit or the RTA to a 1P 4wTs are summarized in Table III. 
Again, balance requirements are identical for a given type of trunk 
switched through either the base unit or an RTA. 

The balance requirements listed in Tables II and III are given in 
terms of echo return loss (ERL) and singing return loss (SRL) as 
measured at the 4wTs (or equivalent) using a return loss measuring 
set (RLMS). An ERL measurement is a weighted average measurement 
of the return losses for each frequency in the echo frequency range. 
An SRL measurement is the lesser of two weighted average measure- 
ments of the return losses, one measurement covering the frequencies 
at the lower end of the voice frequency band and the second covering 
frequencies at the upper end of the voice frequency band. 

No resistance build-out capability is provided in the balancing 
networks of the various 4wTs (or equivalent) used in TSPSs applications. 
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Therefore, to meet specific balance requirements at any given 4wTS 
maximum allowable lengths of office cable (26-gauge switchboard cable 
in both base units and RTAs) between the points of good impedance of 
the trunks and their 2-wire appearance on the base unit switching 
network or RTA concentrator have been specified. Those segments of 
switchboard cable in which length must be controlled are labeled “sB 
CABLE” in Figs. 4 and 5. 

In a given base unit or RTA, the value of the NBoc in the balancing 
networks of all the 1P 4wrTss will be set to some compromise value 
such that the balance requirements are met on connections through 
the switching network to all possible 2-wire TcTs. To meet balance 
requirements when the value of the NBoc is fixed, variation in the 
shunt capacitances of the switchboard cables shown in Figs. 4 and 5 
must be controlled. If the switchboard cabling capacitance variation is 
sufficiently large, balance requirements will not be met on all possible 
connections if the value of the NBOC is to remain single-valued. 

It should be noted that the shunt capacitance of the switchboard 
cabling between a 1P 4wrTs and the point of good impedance of any of 
the various trunks using 4-wire facilities shown in Figs. 4 and 5 will, in 
general, be much smaller than the value of the NBoc in the hybrid 
balancing network of the 1P 4wtTs required to meet balance require- 
ments on connections to TCTs providing 2-wire bridging access. To 
reduce this cabling capacitance variation, bridged capacitance is added 
to the shorter 2-wire switchboard cabling paths to increase their 
effective shunt capacitance and make them equal that of the longer 2- 
wire cabling paths. This is accomplished by adding a drop build-out 
capacitor (DBOC) in the shorter 2-wire cabling paths as indicated in 
Figs. 4 and 5. In some cases, the DBOC is supplied as part of the TsPs 
or RTA trunk circuit or as part of the 4-wire bridging repeater. In other 
cases, a separate DBOC is supplied and wired on a bridged basis across 
the 2-wire switchboard cabling path between the point of good imped- 
ance of a given trunk and its appearance on the base unit switching 
network or on the RTA concentrator. 

Terminal balance requirements are imposed on connections in a toll 
office from any intertoll trunk to any TcT. When the TCT provides TSPS 
bridging access, the same terminal balance requirements apply. The 
current toll office terminal balance requirements listed in Table IV are 
for the most part independent of the type of toll office involved, but 
are dependent upon the general makeup of the TcT facilities. To meet 
terminal balance requirements on 2-wire TCTs providing TsPs bridging 
access, the maximum length and the gauge of the switchboard cabling 
used to interconnect the base unit or RTA incoming trunk circuit, the 
toll office, and the point of good impedance of the TcT facilities (e.g., 
4-wire terminating set, impedance compensation network) must be 
controlled as a function of (z) the type of toll office, (zi) the length and 
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Table IV—Toll office balance requirements 


1. Terminal balance 
a. 2-wire facilities with 2-dB pad (intrabuilding): 
ERL: 22 dB* median, 18 dB minimum 
SRL: 14 dB median, 10 dB minimum 
b. 2-wire facilities or 4-wire facilities with 2-wire extensions (interbuilding): 
ERL: 18 dB median, 13 dB minimum 
SRL: 10 dB median, 6 dB minimum 
c. 4-wire facilities: 
ERL: 22 dB median, 16 dB minimum 
SRL: 15 dB median, 11 dB minimum 
2. Through balance 
ERL: 27 dB median, 21 dB minimum 
SRL: 20 dB median, 14 dB minimum 


* 20 dB for No. 5 crossbar toll offices only when TcT provides Tsps 2-wire bridging 
access. 


gauge of switchboard cabling internal to a 2-wire toll office, and (iiz) 
the value of the NBoc of the balancing network of the intertoll hybrids 
in a 2-wire toll office. 

The terminal balance requirements listed in Table IV also apply to 
connections through the toll office from any CAMA transfer trunk, TSPS 
inward trunk, or TsPs delayed call trunk to any Tct. The toll-office 
through balance requirements also listed in Table [IV must be met on 
connections through the toll office between any TsPs inward or delayed 
call trunk and any intertoll trunk. These balance requirements have 
been imposed to limit any degradation in the quality of the echo 
performance provided on the overall connection resulting from the 
introduction of additional 2-wire switching points in the overall con- 
nection between customers. To limit degradation of the echo perform- 
ance provided on the overall connection between two customers re- 
sulting from the increased round-trip propagation delay of the echo 
path caused by adding either a TspPs inward or a delayed call trunk in 
tandem with the overall connection, the maximum route length of the 
facilities composing each of the two portions of an inward or delayed 
call trunk must not exceed: 


(t) Metallic facilities 9 miles 
(it) T-carrier facilities 50 miles 
(tii) T-carrier with metallic Determined by the requirement that 
extensions the length of the T-carrier facilities 


plus 10 times the length of the me- 
tallic extension must not exceed 50 
miles. 


IV. ADDRESS SIGNALING AND SPECIAL SIGNALING 
4.1 Signaling methods 


RTA trunks utilize classical loop and E&M supervisory signaling 
methods. Nonsupervisory signal handling, however, is different. 


RTA TRANSMISSION AND SIGNALING 1157 


Signaling between the RTA and the local or toll switching offices 
typically assumes one of two forms: (1) ac multifrequency tone bursts 
and (ii) de pulses or “winks.” When MF tones are used, the signaling 
_ is usually between the local or toll offices and the base unit with the 
RTA essentially transparent. This is the case for MF address signals, 
automatic calling number identification (ANI), and inband coin control 
and ringback. When dc pulsing is employed, however, signaling is 
restricted to the relatively short trunks between the RTA and the local 
and toll offices. This is the case for dc dial pulses and multiple wink 
(MW) coin control, ringback, and ringforward. 

The RTA does not provide +130 V dc signaling for coin control, but 
does provide +130 V dc simplex signaling for ringforward toward the 
toll office. 


4.2 Dial pulse receiving 


It would be nearly impossible for dc dial pulses (DP) generated at an 
originating office to pass through the RTA and over the extremely long 
BR trunks that could be encountered and still be reliably detected by 
a digit receiver at the base unit. An alternative way of handling DP at 
the RTA is required. Rather than being transmitted to the base, dial 
pulses received at an RTA are blocked in the trunk circuit where they 
are counted and encoded by the Position and Trunk Scanner (PTs) 
circuit in the PcL. The value of each dialed digit is then transmitted in 
the interdigital interval to the spc over the PCL data links and not over 
the normal voice transmission facilities. 

When all the called digits have been obtained, the spc must deter- 
mine if the originating office is equipped with ANI (automatic number 
identification). If it is, an MF receiver must be connected to the Tl 
port of the RTA incoming trunk via the base networks, a BR trunk, and 
the RTA concentrator. The trunk circuit is then directed to send an off- 
hook “wink” to the originating office requesting transmittal of the 
calling number. The MF tones then follow essentially the same path 
used to connect an operator to the calling customer. Hence, in the 
design of the toll-connecting and BR trunks, consideration must also 
be given to signaling. 


4.3 Multifrequency receiving 


If the RTA incoming trunk is identified as having MF rather than dial 
pulse signaling, the spc establishes a transmission path to a base unit 
MF receiver in much the same manner as described above to receive 
the ANI digits after dial pulsing. Once a transmission path is estab- 
lished, the RTA is directed to signal the originating office via a 200-ms 
off-hook wink to start MF pulsing. After all the called number digits 
have been registered, the spc must determine if the originating office 
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is equipped for ANI and, if so, must signal the office to forward the 
calling number. This is done by directing the RTa trunk to go off-hook. 
Thus, in the case of MF originating traffic, the signaling and the voice 
transmission paths are identical. 


4.4 Multifrequency outpulsing 


Once the called number has been registered by the spc, it must be 
forwarded or outpulsed to the toll office to effect call completion. Since 
this is normally done at the same time that an operator is connected 
to the calling customer (acknowledging coin deposits, getting special 
billing information, etc.), a second transmission path must be estab- 
lished, this time via the T2 port of the incoming trunk circuit. In the 
case of-an RTA call, the MF outpulser circuit is connected to the trunk 
via a BR trunk and the RTA concentrator. 

MF signals transmitted from TSsPs to the toll office, therefore, follow 
a somewhat different route than voice signals, traveling via the T2 port 
of the trunk circuit while voice signals use only the T1 port. In the 
case of the relatively simple 2-wire trunk circuits, this makes little 
difference (see Fig. 6). In the case of 4-wire trunk circuits, however, 
the MF signals do not go through and therefore do not receive 
the benefit of the amplifiers in the associated bridging repeaters 
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Fig. 6—-MF signaling in 2-wire RTA trunk circuits. 
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(see Fig. 7). Thus, the 4-wire circuits require additional amplifiers to 
ensure that the proper ratio of MF to voice is transmitted to the toll 
office. 

Care must also be exercised during the design of the trunk circuits 
and facilities to ensure that they are properly terminated at all times, 
particularly at the 2-wire/4-wire junctions. Improper termination of 
the new 1P 4-wire terminating set can lead to unintentional circuit 
gains or losses with resulting MF signaling difficulties. 

For typical DDD calls, the TSPS must transmit the MF signals only as 
far as the serving toll office which, even for RTa and its toll office, is by 
design over trunk facilities of no more than 0.5-dB loss. With the 
introduction of International Direct Distance Dialing (IDDD) in Ge- 
neric 5, however, TSPS must transmit MF signals to international 
“gateway” offices which may be more than 2000 miles away. On such 
calls, TSPS must first transmit a preliminary set of digits to the toll 
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office which will cause a connection to the gateway office to be 
established. Upon receipt of a signal from the gateway office, TSPs 
must then MF-outpulse the called number. 

Transmission facilities of this length may be made up of many 
segments, be characterized by up to 10 dB of loss, and/or be equipped 
with echo suppressors. Hence, the MF signals must be transmitted from 
TSPS at the current standard level of —7 dBm0 per frequency to insure 
they are not too strong and cause facility overload, clipping, or unac- 
ceptably high crosstalk and are not too weak to be successfully received 
by the gateway offices. 


4.5 Coin control and ringback 


The rTA trunks are all equipped to provide coin control and ringback 
by transmitting either inband (ac) or multiple wink (dc) signals. Inband 
signaling requires the use of the coin control and ringback (CCR) circuit 
at the base unit to supply the inband frequencies. The spc establishes 
a connection between the ccrR and the T1 port of the RTA trunk via the 
base network, a BR trunk, and the RTA concentrator. The RTA trunk is 
then directed to transmit an alerting on-hook wink toward the local 
office followed by a quiet interval of 100 ms. Inband frequencies for 
coin collect (700/1100 Hz), coin return (1100/1700 Hz), or ringback 
(700/1700 Hz) are then generated by the ccr circuit. 

For multiple wink signaling, the RTA trunk circuits are each equipped 
with an integrated circuit which when properly addressed by the PCL 
signal distributor circuit, will generate three winks for coin collect, four 
winks for coin return, or five winks for ringback. One wink and two 
winks, not currently used in the multiple wink signaling arrangements, 
are available for future use. The multiwink generator, however, does 
generate the one wink as an alerting signal for inband signaling and 
for ringforward (see Section 4.6). 

Timing for the multiwink generator is derived from the 12.346-ms 
Position and Trunk Scanner clock in combination with an integrated 
circuit decade counter in each trunk circuit. Hence, the winks appear 
as squared waves with symmetrical 123-ms intervals. 


4.6 Ringforward 


The rtTA trunk circuits can be arranged on an optional basis to 
provide either wink or simplex versions of the ringforward signal. 
Timing for this signal is produced by the same Mw generator in the 
trunk circuits used for coin control and ringback. If the +130-V dc 
supply is connected to the trunk circuit (optional), the ringforward 
signal will be +130-V simplexed onto the T and R leads toward the toll 
office. Otherwise, the T and R leads are simply opened and a wink- 
type signal is sent to the toll office. 
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V. MAINTENANCE FACILITIES 
5.1 CDT modifications 


The control, display and test (cpT) frame at the base unit serves as 
the trunk test panel and also as the primary status display for the TSPs 
peripherals and subsystems. With the introduction of RTA and Pss No. 
2, it was necessary to modify the CDT to accommodate BR trunk and 
pss No. 2 position trunk testing and to add a status display for the PcL 
circuits and data links. A single display is provided which, under 
control of the spc, can show the status of any one of the 15 PCLs 
possible in a given Tsps. This novel display is shown in Fig. 8. 

To meet long-range Bell System objectives on test-tone power levels 
and to prevent crosstalk and other disruptions of carrier systems which 
are likely to be used for the long BR and operator position trunks, the 
CDT was modified to permit trunk testing at power levels 10 dB below 
TLP. Since the base unit, the RTA, and all trunks internal to TspPs (e.g., 
BR trunks) are considered to be at —3 TLP, the test tones utilized will 
be at —13 dBm. Coincident with this change, a system for varying the 
test pad (TP) values was introduced to achieve consistent values of 
expected measured loss (EML) when testing the difference segments of 
a TCT. This multilevel testing scheme is discussed later. 
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Fig. 8—Control display and test circuit frame—PpcL equipment status display. 
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5.2 Test and display circuit 


The test and display circuit (TDC), located at remote RTA and PSs 
No. 2 sites, provides functions similar to those of the CDT at the base 
unit. The TDc provides a PCL display, trunk group status indicators, 
carrier facility and carrier transfer circuit status lamps, and other 
major circuit status lamps. 

A major feature of the TDc is its transmission and noise measuring 
circuit which is similar to the Automatic Transmission Measuring 
System 52A Responder. This circuit takes a “snapshot” measurement 
of the test tone or noise level on a trunk under test and displays the 
results on an LED digital display. The measured results are also passed 
in BCD form to the scanner circuit for transmission via the PCL to the 
base unit. Since the RTA and pss No. 2 sites are likely to be unattended, 
this arrangement facilitates one-person testing of BR and position 
trunks. 

On request from the cpT, the TDC is placed in a remote control 
mode, responding to commands from the sPc transmitted via the PCL. 
In this mode, the following tests can be made either semiautomatically 
or by automatic progression from one test to the next and for each 
trunk in the trunk group: 

(i) Near-to-far end loss: Measurement is made by the TDC, trans- 
mitted to the base, and printed on the maintenance center TTY. 

(zi) Far-to-near end loss: Measurement is made on a transmission 

measuring set built into the cpDT. . 

(iit) Near-to-far end noise: Measurement is made as in test (1). 

(iv) Far-to-near end noise: Measurement is made on a 3B noise 

measuring set built into the cDT. 

In its local mode, the TDc is used to test the segments of the TCTs 
between the RTA and the local offices and between the RTA and the 
toll office. It can also be used for 2-person testing of BR or operator 
position trunks. As with the cpT, tests on these circuits are made at 10 
dB below TLP. Test jacks are provided at the TDc to facilitate the use 
of portable test equipment in testing the PcL data links, TCTs, BR 
trunks, and the teletypewriter data channel. 


5.3 Dial access test lines 


A new transmission maintenance facility introduced concurrently 
with Generic 7 is the Dial Access Test Line circuit or DATL. The DATL 
circuits, located at both the RTA and the base unit, provide the 
equivalent of a code-100 test line (quiet termination), a code-102 test 
line (milliwatt 1000-Hz tone) and a code-106 test line (loop-around). 
These circuits permit maintenance craft at the local and toll offices to 
reach a TSPS test termination by simply dialing a test code, typically 
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959-120X for the quiet termination or 959-122X for the milliwatt tone 
(the ““X” signifies that the last digit is immaterial). 

Each DATL has two ports, each of which can supply a quiet termi- 
nation or milliwatt tone. When two trunks in the same trunk group 
access the DATL at the same time, the spc will automatically loop the 
trunks to each other through the DATL. To prevent this arrangement 
from being used as an unauthorized “meet me” circuit, the DATL is 
equipped with 60A control units which are designed to pass signals 
within a very narrow passband centered at 1004 Hz. If energy outside 
this band and above approximately —30 dBm is detected, the 60A will 
open the loop. The loop-around path produces an EML twice that of a 
l-way connection. 


5.4 Maintenance improvements 


The introduction of multilevel testing at the cbT and TDc frames 
constitutes a noteworthy transmission maintenance improvement. In 
this scheme, the values of the test pad is changed depending upon the 
direction of the tests, that is, toward the local office, toll office, base 
unit (for the TDC), or RTA (for the cpT). Testing a toll-connecting trunk 
associated with TsPs (including RTA) may also involve testing the TCT 
segments. There are three possible tests: local office to toll office, local 
office to TSPS, and toll office to Tsps. Note that each switching center 
can list a given trunk with two different terminating offices, yielding 
the likelihood of two different EMLs for the same circuit. Test-pad 
switching at the cpT and Tpc eliminates that condition. 

Consider a TCT with Ici of 3 dB being tested between a local office 
and a toll office equipped with a typical 2-dB test pad. The EML at 
both offices would be 5 dB. However, if the same TCT circuit is tested 
between TSPs and the toll office when the IcL of the TcT segment is 
0 dB, the toll office would now measure 2 dB. To eliminate this 
inconsistency, 3-dB test pad is inserted at the CDT (or TDC) to make 
the toll office measurement 5 dB. Similarly, if the TCT segment between 
the local office and the TsPs is tested, the local office would now 
measure 3 dB (the Ic value) or possibly 6 dB if the cDT or TDC test 
pad is 3 dB, as above. Instead, the cpT (TDC) test pad is switched to 2 
dB, making the measurement at the local office a consistent 5 dB. 

Since the Tsps base unit can be associated with more than one toll 
office, the CDT is equipped with test pads of 0, 2, and 3 dB to simulate 
the test pads found in Bell System toll offices. The Tpc may have only 
one toll test pad value, 0, 2, or 3 dB. 


VI. CONCLUSION 


The introduction of RTA and pss No. 2 with their long BR and 
operator position trunks required establishment of a new comprehen- 
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sive transmission plan. Several existing base unit circuits had to be 
modified or completely redesigned to meet tightened transmission 
standards. Equipped with the new 3-way, 4-wire bridging repeaters, 
unified telephone circuits, and precision 1P 4-wire terminating sets, 
the RTA and pss No. 2 provide generally equivalent, if not better, 
transmission quality to that which previously existed in TSPS. 
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The principal data-handling circuits used between a TSPs base 
location and remote sites up to 1000 miles distant are described. 
Included are novel operational programming and fault recognition 
features required by this large separation between the processor and 
its peripherals as well as by the uniqueness of certain remote units. 
The RTA’s use of remotely run diagnostics and multi-unit initializa- 
tion schemes for fast recovery from outages ts also covered. 


l. INTRODUCTION 


Early in the rTA planning process, it was recognized that controlling 
trunks, networks, and test circuits remotely was a task similar to 
controlling operator positions, voice path circuits, and test circuits 
remotely; i.e., the RTA job would be similar, in several aspects, to the 
work planned for development of a new position subsystem. These 
configurations are shown in Fig. 1. These job similarities led to devel- 
opment of a set of data-handling circuits known as the Peripheral 
Control Link (PcL) used to link the remote hardware to the controlling 
processor at a TSPS base location. A Remote Trunk Arrangement (RTA) 
consists of a PCL, various 2-wire and 4-wire trunks at the remote site, 
a concentrator network to temporarily connect these remote trunks to 
a base-remote trunk, a maintenance buffer, and a trunk test frame. A 
Position Subsystem (pss) No. 2 consists of a PCL, several operator 
positions, some supervisory and chief operator circuits, a voice path 
control frame, a maintenance buffer, and a test frame. 

The pss No. 2 is only briefly treated in this paper and is mentioned 
at this time to indicate another consideration in PCL design—a desire 
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Fig. 1—RTA/pss No. 2 common equipment. 
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to keep the pct general purpose and to have its data rate high enough 
to handle bursts of operator activity. In both the RTA and the pss No. 
2 configurations, the remote circuits (trunks or positions) are tempor- 
arily connected to the base Tsps network in processing a call. In the 
RTA case, a base-remote trunk is used so that various “service” circuits 
at the Tsps base location (digit receivers, outpulsers, tones, announce- 
ments, etc.) can be connected to the RTA trunk as needed. In the pss 
No. 2 case, operators at remote positions are temporarily connected 
through the base Tsps network to customers placing toll calls requiring 
operator assistance. The many voice circuits required in each case (up 
to 64 base-remote trunks or operator voice paths) utilize carrier trans- 
fer circuits and carrier failure detection circuits to permit fast, proces- 
sor-controlled switching to spare carrier groups in the event of trouble. 
This carrier group switching is similar to that used in other switching 
designs and is only briefly discussed in Section 2.5. 

The PCL includes a base location data conversion circuit known as 
a group gate, outside plant facilities, remote data circuit, signal distrib- 
utor, scanner, and diagnostic control circuit. Each of these circuits 
consists of two identical halves and are arranged in two separate PCL 
halves with triplicated transmission facilities as shown in Fig. 2. A PCL 
half is capable of sustaining all communications and control between 
the Stored Program Control (spc) and the RTA or pss No. 2 circuits. 
When both pct halves are in service, a state referred to as “duplex,” 
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Fig. 2—Peripheral control link. 
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the PcL throughput remains the same, but the error detecting capabil- 
ities of the pcL are increased. Several reliability studies’’ have shown 
the transmission paths to be the weakest link and other studies have 
shown matching to be one of the best methods of error detection. This 
led to use of triplicated facilities so that duplex operation with match- 
ing can be continued even with a facility outage. Operation without 
matching is also possible so that, while error-detecting capability is 
lessened, complete RTA or PSS No. 2 operation can continue with two 
simultaneous facility outages. When a PCL half is out of service, the 
PCL is said to be in a simplex state. 

The RTA equipment not considered part of the PcL is not duplicated. 
However, control of this part of the RTA is distributed over a variety 
of individual control devices, such as trunk buffers, concentrator 
controllers, and maintenance buffers. As a result, failure of any one 
control device affects only a small part of the RTA complex. For 
example, a trunk buffer failure would affect no more than 16 trunks. 


ll. HARDWARE AND PHYSICAL DESIGN 


The principal parts of the RTA hardware are the PCL, the concentra- 
tor, and the trunks. Each of these parts is described in this section. A 
test frame, including a 2-way TTy for maintenance messages, is also 
provided and is described briefly in Section 4.5. The principal parts of 
the pss No. 2 hardware are the PCL and the 100C operator positions, 
and the 100C positions are also described in this section. 


2.1 PCL description 


The pct is a general-purpose data link designed to automatically 
retry failing data words so that fault recognition programs will not be 
utilized for minor transmission errors. Four principal checks are made 
on each direction of transmission: parity, cyclic code, sequence check, 
and matching. In general, the data to be sent are applied to both PcL 
halves and treated independently by each half. Then, at the far end of 
the pci, the data from both halves are matched, and a control bit is 
examined to see which PCL half will actually execute the order. Certain 
combinations of matching failures, cyclic code failures, sequence fail- 
ures, and parity failures still permit valid execution of the transmitted 
orders, and these possibilities are discussed in Section 4.1. 


2.1.1 Group Gate and remote data circuit 


The Group Gate (GG) connects the PcL to the address bus, answer 
bus, and Central Pulse Distributor (cpp) of the TsPs processor. A 
Group Gate frame provides up to four fully duplicated Group Gates 
and the common bus input/output circuits to send and receive data to 
all four. This common bus circuitry initially accepts a 21-bit binary 
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word from the address bus and passes it to all Group Gates on the 
frame. An enable signal from the cpp then designates which Group 
Gate should respond to this particular 21-bit word, ie., there is a _ 
separate enable signal for each Group Gate on the frame. There is also 
a common enable designating whether this order is “odd” or “even,” 
and circuitry at the remote end continually checks that an alternating 
pattern of odd and even words is received. 

The Group Gate also functions as a parallel-to-serial converter (in 
the sending direction) and thus converts the 21-bit parallel data into 
a 21-bit serial bitstream. The odd/even bit mentioned above is added, 
and a 2-bit “start” code is also added to designate the start of a new 
transmission and also to designate whether the new word is a long 
word (data from the TsPs processor) or a short word (scan complete 
signal from the processor). The resulting 24-bit serial word (long word) 
is then passed through a cyclic code generator which appends a 5-bit 
cyclic code. The resulting 29-bit serial word is fed to a 2400-b/s data 
set which performs a digital-to-analog conversion and connects to the 
transmission facility. (The “short word”—an acknowledgment signal 
from the processor that the last transmission from the distant end was 
received correctly—is 11 bits long as it is passed to the data set.) In 
normal (duplex) operation, both halves of a Group Gate receive the 
21-bit word from the address bus and generate the 29-bit analog pulse 
streams to the two transmission paths. However, it is also possible to 
split the PCL into two (simplex) halves, and in this mode each half can 
be sent a different order from the processor. 

In the receiving direction (Fig. 3), each Group Gate half receives an 
analog pulse stream into the 2400-b/s data set where it is converted to 
a digital bitstream. This is passed to a cyclic code check circuit and a 
parity check circuit. A processor-controlled activity bit designates one 
Group Gate half as “active” and the other as “inactive.” Both halves 
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perform all the actions outlined above, but only the active half controls 
the matching operation. After the cyclic code and parity checks are 
performed, the active half moves data from both halves through a 
serial-mode matching circuit in the active half and determines if the 
match is valid or invalid. If cyclic code and parity tests have passed 
and matching is valid, then a signal is sent to the TsPs processor that 
the Group Gate has information ready to be passed on. If only the 
active half passed the cyclic code and parity checks and matching with 
the inactive half is not valid, then, again, the processor is signaled that 
information is present. A CPD pulse from the processor then causes 
that Group Gate to send its information on the processor answer bus. 

For other combinations of invalid data and for transmission “burst” 
errors” affecting more than 1 bit and detected by the cyclic code check, 
a signal is sent to the remote end to retransmit the data. The processor 
is also informed that a retransmission or several retransmissions are 
taking place and, depending upon the severity of the problem, certain 
fault recognition routines may be executed. For example, the error 
activity might indicate a bad transmission facility on one PCL half, and 
the corrective action would be to switch to a spare transmission 
facility, or the error might be a simple transmission “hit” or “burst” 
which is cleared up by a retransmission, and no other maintenance 
activity is required. 

The Group Gate can also receive processor data into a maintenance 
register which sets up any of several specialized maintenance states 
within a Group Gate half. For example, the cyclic code generator can 
be configured to purposely output bad codes so that subsequent PCL 
circuits can be exercised. The sending portion of a Group Gate half 
can also be connected back to the receiving portion of the same Group 
Gate half so that data from the TsPs processor can be operated upon 
by the Group Gate and returned to the processor as part of a diagnostic 
routine. 

The Remote Data Circuit (RDC) is very similar to a Group Gate and, 
in fact, uses many of the same circuit packs designed for the Group 
Gate. However, it is located at the remote end of the PcL and connects 
to the signal distributor and the scanner. Like the Group Gate, it 
performs parallel-to-serial and serial-to-parallel conversions, parity 
checks, cyclic code generation and checking, odd/even sequence check- 
ing, and matching. The remote data handling circuits are mounted on 
a double-bay frame such that one side of the frame contains all the 0 
half circuits and the other bay contains all the 1 half circuits. The two 
RDC halves, including their respective 2400-b/s data sets, each comprise 
one 6-in. mounting plate on the two bays of the frame. This frame, 
called the position and trunk control frame (for use both in pss No. 2 
and in RTA) is shown in Fig. 4. 

Whenever no new data transmissions are available from either the 
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Fig. 4—Position and trunk control frame. 


processor (for the Group Gate) or from the remote scanner (for the 
RDC), a dummy word is sent over the PcL. Thus, the PCL is sending 
information back and forth every 25 ms even during inactive periods. 
Both the Group Gate and RDc have the ability to recognize nonreceipt 
of such interchanges as a mechanism for identifying transmission 
facility troubles. In addition, the rpc, after several seconds of not 
receiving any words (dummy or data) from the Group Gate, will split 
the remote PCL end into two simplex halves. This action is based on 
the assumption of a trouble which has been recognized at the base 
(processor) location and has somehow prevented orders (to switch to 
simplex) from being executed at the remote location. The automatic 
switch to simplex operation then allows the fault recognition programs 
to exercise both halves and all three transmission facilities so as to 
find a good configuration. 


2.1.2 Position and Trunk Scanner 


The scanner is considered a part of the PCL, but introduces the 
concept of distributed control, since much of it is physically mounted 
on the trunk frames and 100C consoles with which it works. This 
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distributed concept means that only that portion required need be 
equipped, i.e., as a new trunk frame is added to an office, another piece 
of the scanner is essentially added to the scanner. This new piece of 
the scanner was furnished as a part of the trunk frame just added and 
deals with supervisory signals from those added trunks. It is then 
connected to the rest of the scanner which is provided as two inde- 
pendent halves, each reporting changes of state to the processor at the 
TSPS base location. At the base location (in the Group Gates, as 
described in Section 2.1.1), the two scanner reports are matched before 
actual transmission to the processor. Mismatch errors are a prime 
means for detecting scanner malfunctions (see Section 4.1 below). 

The scanner is an autonomous circuit continually looking for tran- 
sitions such as changes in trunk supervision, depression of a key on a 
position, or test frame and system alarms. It is driven by a clock signal 
obtained from the 2400-b/s data set used by the RDc and both scanners 
are run from a single data set clock. However, this clock signal is 
continually checked and both scanners will switch to the other data 
set (RDC) clock in case of trouble. For simplex operation, the two 
scanners each connect to the corresponding individual rpc clocks. 
Minute differences in the two Rpc clocks require a period of synchro- 
nization as two simplex scanner halves are reconfigured into a single 
duplex system. 

The scanner examines some 1300 scan points every 12.3 ms and 
records the state of each in Random Access Memory (RAM). In the 
next 12.3-ms cycle, the previously recorded information is known as 
the “Last Look” (LL). At any instant of time, the current state of a 
scan point on which the scanner is currently acting is-known as the 
“Present Look” (pL). The scanner also keeps track (in RAM) of the 
previously reported state of each scan point. This is known as the 
“Previous State” (PS) and is the state last reported to the.TSPs 
processor. As the scanner examines each point, it compares the PL to 
the LL and ps. If the PL and LL agree and are different from the Ps, 
then a report is made and Ps is changed to the new value. The 
requirement that two scans spaced 12.3 ms apart must agree allows 
the scanner to disregard all transient conditions producing pulses 
shorter than 12.3 ms and guards against line and supervisory transients 
being reported as valid trunk states. 

Although both scanners are running on a single clock during duplex 
operation, there is a low probability chance that one scanner half will 
see a scan point transition one scan interval ahead of the other. Then, 
on the next scan, one scanner will make a report while the other 
scanner has seen the transition for the first time and will not make a 
report. On the third scan, the second scanner would make its report 
and from that point on the internal scanner states should be in 
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agreement. But in the meantime, a mismatch at the Group Gate may 
have been detected and some fault recognition activity would be 
triggered needlessly since the mismatch does not indicate a hard fault. 
To prevent this transient mismatch, a match on the present look 
between the scanners is performed. If a mismatch occurs at this point, 
then both scanners ignore the present look in this scan period. On the 
second scan, if the mismatch was not a hard fault, both scanners will 
agree and a report will be made in the normal fashion. If the mismatch 
persists through the second scan, both scanners are again allowed to 
proceed in a normal fashion but in this case a mismatch will be 
generated and the hard fault will be detected. A single bit per scan 
point is required to count the present look mismatches (PLMM) and 
this bit is kept in RAM along with the LL, Ps, and a parity bit for RAM 
self-checking. 

The scanner presents reports to the RDc which adds cyclic code and 
converts to a serial analog pulse stream. The RDC accepts the scanner 
reports at a maximum rate of one every 25 ms, depending upon data 
line activity. However, the scanner input rate is based on whatever 
activity is happening at some interval of time and could conceivably 
be much greater than a 25-ms rate for brief periods of time, i.e., bursts 
of operator activity whereby several operators simultaneously push 
keys or RTA trunk activity involving dial pulse reception on several 
trunks. Also, the 25-ms output rate may be slowed due to transmission 
line errors which require retransmissions. To cope with such activity, 
the scanner contains a 32-word output buffer so that reports can be 
stored temporarily until they are transmitted. Calculations indicate 
that, even with bursts of operator and trunk activity, a 32-word buffer 
will almost always guarantee that no information will be lost.* Excep- 
tions can occur during severe (but very infrequent) maintenance 
activity, when scanner reports accumulate while fault recognition is 
running maintenance tests under partial outage conditions. 

A feature of the scanner is its ability to count dial pulses on the 
incoming (local office) side of every trunk, recognize the interdigit 
interval, and report dialed digits to the TsPs processor. It also performs 
timing checks on initial state changes from the local office side of a 
trunk to recognize “false seizure” conditions so as to not report such 
false seizures (these can persist for up to 40 ms). These features are 
based on defining several possible trunk states such as initial seizure, 
start of open interval of a dial pulse, start of closed interval of a dial 
pulse, start of interdigital interval, end of pulse, end of digit, disconnect, 
etc. A trunk progresses from state to state by timing the number of 
12.3-ms cycles in which it remains in an on-hook or off-hook condition. 
Thus, each time the trunk condition changes, a count of 12.3-ms cycles 
is started (by incrementing a 4-bit count—4 RAM bits—assigned to the 
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incoming side of each trunk). The actual count reached before the on- 
hook/off-hook condition changes determines the next state of the 
trunk. For example, consider a trunk receiving dial pulses which, after 
a few pulses of a digit, starts counting the 12.3-ms cycles of an off-hook 
interval. If 2 to 10 cycles are counted and then the trunk condition 
changes to on-hook, this is considered another pulse of the digit, and 
the on-hook interval is timed to confirm this. However, if 11 or more 
(off-hook) 12.3-ms cycles are counted, this is considered an interdigital 
interval and the previously counted pulses now represent the digit to 
be reported. 

The items scanned by the scanner include trunk supervisory inputs, 
100C console keys, and alarm indications from all remote circuits. The 
reported information consists of scan point type, unit number, and the 
particular status change of that unit (such as operation of the START 
TIMING key at a position). A parity bit and a sequence number are 
added by the scanner. The sequence number is a continuously incre- 
mented 2-bit binary number (0-1-2-3-0-1----) indicating the order in 
which reports are loaded by the scanner into its 32-word output buffer. 
The rpc adds a start code, a 5-bit cyclic code as described for the 
Group Gate in Section 2.1.1, and sends the report back to the TSPs 
processor. At the processor, this sequence code from the scanner is 
continually checked and any out-of-sequence condition is a trigger for 
fault recognition action. This guards against a report being lost with 
no indication to the processor that the lost report ever existed. 

The scanner is constantly performing self-checks as it scans across 
certain scan points reserved for maintenance self-checks. For example, 
one scan point is arranged to give on-hook/off-hook sequences that 
should represent a certain digit count and other circuitry within the 
scanner checks that this count has been reached. These checks, in 
addition to parity checks across the RAM, influence an “all-seems-well” 
bit returned with each scanner report and are constantly examined by 
the Tsps processor. A failing “all-seems-well” bit triggers immediate 
fault recognition action. 


2.1.3 Signal distributor 


The signal distributor takes parallel information from the RDC, strips 
off the unit designation and unit type information (such as position 
number, trunk buffer number, concentrator controller number, etc.), 
and distributes the remaining portion of the order to the designated 
unit. In performing this distribution, it converts the parallel output of 
the RDC to a serial bipolar bitstream and adds parity and start bits. 
The resulting serial word is transmitted over a single pair of wires to 
an RTA trunk buffer, a 100C console (Pss No. 2), a concentrator 
controller, a maintenance buffer, or to the test frame. Thus the signal 
distributor communicates with 70 to 80 units of five different types. 
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(For a pss No. 2, this consists of 62 positions, 5 maintenance buffers, 
2 test frame buffers, and 1 self-test buffer. For an RTA, this consists of 
31 trunk buffers, 5 maintenance buffers, 2 test frame buffers, 40 
concentrator controllers, and 1 self-test output). The serial bit-bipolar 
transmission allows these units to be several hundred cable feet from 
the signal distributor. 

After the serial word is constructed within the signal distributor and 
loaded into an output shift register, it is then shifted out and, at the 
same time, looped back into the output register. Thus, when shifting 
(transmission) is complete, the transmitted word is again in the output 
register and is rechecked bit by bit for accuracy. Both this check and 
a subsequent flip/flop activity check made by the receiving unit (100C 
console, trunk buffer, etc.) influence the check-back signal sent from 
the signal distributor back to the RDC, and subsequently to the spc, as 
an overall check. This shifting action also allows calculation of a parity 
bit “on-the-fly,” i.e., as the information and start bits are shifted out, 
parity is calculated and, if the shift register recheck passes, the correct 
parity bit is appended to the end of the serial transmission. Thus the 
parity bit can be purposely “failed” to keep the receiving unit from 
using questionable data. 

The start code not only identifies the start of a new transmission 
but also identifies the type of unit expected to receive the new infor- 
mation. Each receiving unit contains a start code mask that must 
match the start code to accept the information bits. Each receiving 
unit (buffer) also generates either a “check-back” or a “buffer failure” 
response to the signal distributor each time it receives new information. 
This response is returned to the distributor over the same pair of wires 
used to send information to a buffer. This response, together with the 
signal distributor’s internal checks, is used to send a check-back signal 
to the RDc and from there to the spc. If the spc fails to receive this 
check-back, fault recognition action is triggered, starting with a simple 
retry and escalating to subsystem reconfigurations if necessary. 

The duplex nature of the sending portion of the PCL effectively ends 
at the RDC and, once RDC matching is complete, only one of the 
duplicated signal distributors executes the order. The distributor cho- 
sen by the RDC is changed on every order to utilize both distributors 
evenly. If the PCL is split into two independent halves for maintenance 
purposes, then maintenance orders can use one signal distributor while 
call processing orders use the other. 

The orders to light LED numerical displays in 100C consoles place 
special requirements on the signal distributor. These orders are always 
sent as a sequence of 2 to 7 consecutive spc orders, but only the first 
contains the address of the desired 100C console. The signal distributor 
recognizes such orders (usually called “prime” orders since they prime 
the distributor and the 100C console to expect a sequence) and tem- 
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porarily stores the position number while passing the rest of the order 
to the desired position. Subsequent spc orders will contain pairs of 
digits to be selected on the console LED display but do not include a 
position number. Since only one signal distributor executed the 
“prime” order and remembers the position number, that one distrib- 
utor handles all of the rest of the sequence and the alternating use of 
both signal distributors is temporarily suspended. 

The “prime” order also informs the distributor as to which of several 
types of LED displays will be forthcoming; e.g., a 12-digit (including 
blanks) display of a called number, a 1-digit display of elapsed minutes, 
a 6-digit display of the time-of-day, etc. The distributor includes a 6- 
unit ring counter that chooses the location, within the operator’s 
numerical display, where the pair of digits just received are to be 
placed. This ring counter is preloaded by the prime order to start the 
first pair of digits (next spc order) in the correct position on the 100C 
console. The ring counter is then stepped along by each subsequent 
order so that it is always ready to direct the digits to the proper place. 
As the signal distributor forms the 23-bit serial word to the 100C 
console it takes the digit pair values from the RDc, the pair location 
from the ring counter, and the 100C address from its stored memory 
of that address, and adds a parity bit computed on-the-fly as the other 
information goes by. 


2.1.4 Diagnostic control circuit 


The diagnostic control circuit (DCC) is also considered part of the 
PCL as shown in Fig. 2. It allows implementation of a remotely run 
diagnostic concept explained in Section 4.3. The overall description, 
together with its control by the spc and its considerable access to 
remote PCL circuits, are all included in Section 4.3 as part of the RTA 
maintenance plan. 


2.2 Concentrator 
2.2.1 Size, ratio, components 


The RTA concept is to provide TSPS services for a sparsely populated 
area from a TSPS in a more built-up area. Therefore, many RTA 
installations consist of 200 to 400 trunks arranged in many small trunk 
groups with relatively low occupancy. Initially, only 100 to 150 trunks 
may be required, with growth to 300 to 400 taking place over several 
years. A few RTA sites will have larger trunk groups and correspond- 
ingly higher occupancy and a few will have trunks exceeding the 
capacity of a single RTA and use two RTAs in the same building. 

Early studies of the potential RTA market and of trunk usage led to 
the conclusion that the base-remote trunks (from the output side of 
the concentrator to the controlling Tsps base installation) will be 
connected to a call for about one-eighth of the total holding time.’ 
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Several concentration ratios were evaluated based on trunk numbers 
mentioned above, and the 8:1 concentrator was selected as the best 
compromise. The compromise was such that a slightly more expensive 
concentrator is initially provided but growth, on both the basic con- 
centrator and the subsequent addition of a build-out frame, is easily 
accomplished. The 8:1 concentrator works well with lightly loaded 
offices, allows up to 496 incoming trunks, and provides for flexibility in 
load balancing. With a full complement of base-remote trunks (up to 
64), it also works well in moderately heavily loaded offices. 

The desire for a low-cost, easily-added-to, and moderately-long- 
holding-time switch led to use of miniature crossbar switches as the 
principal concentrator element. In RTA use, the select mechanism of 
the crossbar switches will accumulate its lifetime operations (estimated 
at 20 to 25 million operations) in 7 years. Ease of replacing this 
mechanism plus widespread operating company familiarity with such 
work also influenced the crossbar switch choice. 


2.2.2 The logical concentrator and the physical concentrator 


The logical layout of the concentrator is used to understand the 
connection pattern and to assign switch numbers useful to the Tsps 
programs controlling concentrator operations. However, the physical 
construction of the concentrator makes use of 20 x 10 crossbar switches 
arranged in a rather specialized way to achieve the 16 by 8 and 32 by 
8 switches of the “logical” concentrator. This section explains the 
relationship between these two views of the concentrator. 

The concentrator may be obtained in two sizes: a “small” size, able 
to connect up to 248 remote incoming trunks to as many as 64 base- 
remote trunks, and a “large” size, which can handle up to 496 remote 
incoming trunks. In each size, every remote trunk has full access to 
each of the up to 64 base-remote trunks. The term “remote trunk” is 
used broadly here to mean any trunk circuit which appears on the inlet 
side of the concentrator, while the term “remote incoming trunk” 
means specifically an RTA incoming trunk. A variety of possible remote 
trunks besides remote incoming trunks includes: hotel/motel auto- 
quote trunks, inward trunks, and test appearances. With the exception 
of test appearances, if any of these other types of remote trunks appear 
on the concentrator, they must replace remote incoming trunks so that 
the maximum number of the latter is reduced accordingly. 

2.2.2.1 The Logical Concentrator. Figure 5 is a simplified depiction 
of the Logical Concentrator. In the small sizes, the first or trunk stage 
consists of thirty-two 16 by 8 three-wire crossbar switches, while the 
second or base-remote stage has eight 32 by 8 three-wire switches. The 
small Logical Concentrator thus has 512 inlets (2 for each of the 248 
remote incoming trunks, 2 for test appearances, and 14 spares), 64 
outlets (one for each of the 64 base-remote trunks), and 256 links (one 
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Fig. 5—The logical concentrator and its numbering. 


from each of the 32 trunk stage switches to each of the 8 base-remote 
stage switches). 

The large Logical Concentrator is obtained by adding a 16 by 8 
three-wire buildout switch to each of the trunk stage switches of the 
small Logical Concentrator. It thus has the equivalent of thirty-two 32 
by 8 trunk stage switches and eight 32 by 8 base-remote stage switches 
for a total of 1024 inlets (two for each of the 496 remote incoming 
trunks, two for test appearances, and 30 spares), 64 outlets (one per 
base-remote trunk), and 256 links. 

It is important to note that there is only one possible path or 
“channel” from a particular remote trunk appearance to a particular 
base-remote trunk. By comparison, the base TsPs network has eight 
possible channels from a given inlet to a given outlet. 

To make a connection in the Logical Concentrator from a particular 
remote trunk to a particular base-remote trunk, a single crosspoint is 
activated on the trunk stage switch containing the remote trunk and 
another single crosspoint is activated on the base-remote stage switch 
on which the base-remote trunk is terminated. The first crosspoint 
connects the remote trunk to the link going to the desired base-remote 
stage switch, and the second connects that link to the proper base- 
remote trunk. 
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Fig. 6—The physical concentrator frames and their numbering. 


2.2.2.2 The Physical Concentrator. Because of limitations on the 
type of crossbar switches that are available, the actual hardware 
implementation of the concentrator is quite different from that de- 
scribed above. This hardware implementation is called the Physical 
Concentrator and is shown in Fig. 6. The small concentrator consists 
of two bays of crossbar switches. The first, or trunk stage bay, contains 
thirteen 20 by 10 six-wire crossbar switches, while the second or base- 
remote stage bay contains eight 20 by 10 six-wire crossbar switches. 
The large concentrator is obtained by adding a second frame, similar 
to the trunk stage bay above, called the buildout frame which contains 
thirteen 20 by 10 six-wire crossbar switches. 

To make the 20 by 10 six-wire switches in the physical implemen- 
tation of the RTA concentrator function logically like 16 by 8 three- 
wire switches, a rather complex design has evolved. The first step, that 
of making six-wire switches behave like three-wire switches, is per- 
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formed using a well-known technique’ by which levels 0 and 1 are 
utilized to translate which three of the particular set of six wires are to 
be used. The result of this translation is that the 20 by 10 six-wire 
switches operate like 20 by 16 three-wire switches. These are then 
combined in a fairly complex way to form a unit which operates like 
the Logical Concentrator. 

Thus, in the Physical Concentrator, to make a connection from a 
particular remote trunk to a particular base-remote trunk, two cross- 
points must be activated in the trunk stage switch on which the remote 
trunk is terminated and two more crosspoints must be activated in 
one of the base-remote stage switches to which the base-remote trunk 
is connected. The first of these crosspoints is located in levels 2 to 9 
and connects a pair of remote trunk appearances (six wires) to the link 
going to the desired base-remote stage switch. The second crosspoint 
is located in levels 0 or 1 and selects which of the pair is desired. The 
third and fourth crosspoints perform similar functions in the base- 
remote stage of the concentrator. 


2.2.3 Distributed control 


All the concentrator switch select and hold magnets are operated by 
controller circuits arranged on three plug-in circuit packs. The eight 
groups of packs used for control of base-remote stage switches are 
physically mounted on the concentrator frame and are always pro- 
vided. However, the groups of circuit packs controlling each trunk 
stage logical switch (up to 32) are provided as part of the trunk buffer 
circuit. An RTA office can have up to 32 trunk buffers, 31 of which can 
each contain 16 trunks. Thus, as each group of 16 trunks is added to 
an RTA, a corresponding piece of the concentrator (the three controller 
circuit packs) is also added. The control of the trunk stage portion of 
the concentrator is thus distributed over all RTA trunk buffers arranged 
on up to five separate frames. Some cost saving is obtained by this 
arrangement, since only the portion of concentrator control actually 
required by trunks present in the office are purchased. However, of 
much more importance is the distribution of this control over many 
equipment units and the resulting overall reliability obtained; i.e., 
problems affecting a group of trunks affect only that part of the 
concentrator serving those particular trunks. 

The spc orders distributed to a particular concentrator controller by 
the signal distributor specify the switch number desired, the particular 
select and hold magnets to be used, and the function (connect or 
disconnect). A single trunk stage controller controls two logical 
switches, since each RTA trunk has two appearances on the concentra- 
tor. These two appearances (local office side and toll office side) are 
provided so that an outpulser connection to the toll office can be set 
up while an operator connection to the calling customer is established. 
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[Thus the 8:1 concentration ratio is approximately the ratio of incom- 
ing trunks (up to 496) to base-remote trunks (up to 64), while the ratio 
of trunk appearances is actually 16:1.] In general, the sequence of 
control orders to establish a concentrator connection is as follows: 
Trunk stage connect order, followed by a base-remote stage connect 
order, followed by operation of relays in the selected base-remote 
trunk. A verification test later performed by the base-remote trunk 
circuit results in establishment of a control path via the concentrator 
sleeve lead which locks the trunk stage hold magnet to the base-remote 
stage hold magnet. Connections are broken by a base-remote stage 
disconnect order which resets the base-remote stage hold magnet flip- 
flop and in turn releases both the base-remote and trunk stage hold 
magnets. 


2.3 RTA trunks 


The general approach to trunk design for electronic offices has been 
to keep the trunk simple and temporarily connect it to more sophisti- 
cated equipment for such things as digit reception, ANI reception, coin 
control signal generation, and outpulsing. That this requires many 
trunk and link orders for each call is of little concern when the trunks 
and their associated scanners and signal distributors are close to the 
processor and reached over high-speed buses. However, when the 
trunks are several hundred miles from the controlling processor, and 
when excessive numbers of orders can exceed the capacity of relatively 
slow-speed data paths, the simple trunk concept is not so appropriate. 
Thus the rTA trunks tend to be more complex than their base-location 
counterparts and include several features on a per-trunk basis which 
might otherwise be provided by a separate pool of circuits. 

Another feature of each RTA trunk is that it is packaged on a single 
5 by 7 in. circuit pack. The single Printed Wiring Board (pws) 
construction is made possible by using miniature wire-spring relays, 
miniature mercury relays, miniature networks, and a specially designed 
integrated circuit. A typical trunk is shown in Fig. 7. The custom 
integrated circuit handles several signaling tasks, including coin control 
signals and ringback signals sent from TsPs to the local office. 

The coin control and ringback considerations, including the ability 
to disable or enable a station set TOUCH-TONE® dialing pad at 
certain points in a call, require that five separate signals be sent from 
the RTA trunk to the local office. A custom-made Ic provided in each 
trunk provides these “multiple-wink” signals. The ring-forward signal 
to the toll office is also provided within each RTA trunk. The custom 
integrated circuit uses a 3-bit binary input set as a command to 
generate 1 to 5 pulses, each of which turns on (operates) a pair of 
mercury relays for a timed interval. This pair of mercury relays has 
contacts arranged in the tip-and-ring leads to provide a reversal to the 
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Fig. 7—Typical RTA trunk. 


local office. Thus, 1 to 5 timed reversals (winks) can be sent from an 
RTA trunk. Since this uses only six of the eight possible input states 
(OFF and one to five winks), the other two dre used to operate other 
relays including a set of “ring-forward” mercury relays which apply 
+130 V to the toll office side of the trunk. The 3-bit binary input comes 
from the trunk buffer which generates the 3-bit output from a single 
SPC order. 

With the exception of the use of miniature components and the 
custom integrated circuit mentioned above, many other talking path 
and relay states in RTA trunks are similar to previous electronic office 
trunk designs. The 4-wire trunks utilize the TsPs 3-way 4-wire bridging 
repeaters mounted on separate repeater bays together with the PwB 
on the RTA trunk frame. A group of 16 trunks, together with a trunk 
buffer and appropriate portions of the concentrator controller (Section 
2.2) and of the scanner (Section 2.1.2) comprise a trunk unit. This 
trunk unit has each component part arranged to control only the 16 
trunks of that unit and is thus completely separate from any other 
trunk unit. A malfunction in any portion of the trunk unit will thus 
affect, at most, 16 trunks. 

The trunk buffer is similar to all the buffers to which the signal 
distributor distributes spc orders and consists essentially of a flip-flop 
matrix and the necessary control circuitry to set and reset each flip- 
flop. Output drivers connected to each flip-flop then operate relays in 
the trunks or send signals to the multiple-wink integrated circuit in 
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each trunk of this particular trunk unit. The trunk buffer is provided 
with a “super-initialization” input so that, under severe maintenance 
conditions, an entire buffer or all buffers in the office can be cleared by 
a single pair of spc orders. This initialization path is arranged so that 
all trunks are cleared except those trunks in the cut-through (talking) 
state. Such trunks are assumed to be cleared by the initialization 
routines but are protected by a circuit design that inhibits the action 
of the clear signal when in the cut-through state. The corresponding 
program actions are discussed in Section 3.3. This approach allows 
rapid system initialization when necessary, while at the same time 
' protecting all customer-to-customer talking paths. 


2.4 100C position 


As mentioned at the start of this chapter, the Position Subsystem 
(pss) No. 2 is only briefly mentioned. By adding 100C consoles to the 
PCL described in Section 2.1, together with some voice path switching 
and supervisory circuits, a PSS No. 2 is obtained. The 100C position is 
treated by the PCL signal distributor as one of several “buffer” circuits 
to which it distributes orders. The single exception to this is the 
sequence of orders required to light up a numerical display (1 to 12 
digits) on the 100C console (see Section 2.1.3). A console consists of 
two positions, and throughout the Tsps literature “100C console” and 
“100C positions” are used interchangeably. 

The upper portion of the position consists of two large keyshelf 
printed wiring boards and the LED numeric display PwB. Each keyshelf 
board contains 30 to 50 key/lamps and some integrated circuits and 
discrete components associated with those lamps and keys. The single 
“make” contact of each key connects to a cluster of three diodes, which 
are in turn connected to three leads of a 9-lead bus. Thus each key 
generates a 3-out-of-9 code on this 9-lead bus whenever it is depressed. 
The 9-bit bus is examined by the scanner at regular intervals as 
discussed in Section 2.1.2. The numerical display PWB contains twelve 
7-segment LED numerics and the memory and driving electronics 
associated with them. 

The lower portion of the 100C position contains a dc-to-dc converter 
and several circuit packs of flip-flops, lamp order buffers, and control 
circuits. The control circuit decodes the serial bitstream from the 
signal distributor and determines whether it is part of a numerical 
display sequence or a single lamp order. The numerical display orders 
are delivered with little change to the LED display PwB. The lamp 
orders are formed into a vertical select, horizontal select, and group 
select output set to address a flip-flop matrix. The result is the setting 
or resetting of a single flip-flop and generation of a check-back signal 
to inform the signal distributor that the correct conditions for accessing 
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a flip-flop were present (a sort of all-seems-well signal). In many cases, 
the flip-flop connects directly to a console lamp and simply lights or 
extinguishes that lamp. However, in some cases a console lamp may 
be placed in a flashing state and in such cases the flip-flop output 
connects to a lamp order buffer (LOB). These LoBs generally have two 
flip-flop inputs and a single lamp driver output. One input is used for 
a steady lamp “on” condition, while the other is used to connect the 
lamp to a 60 or 120 1PM interrupter circuit. On a typical call, the Tsps 
processor might initially send several orders to a position causing three 
or four lamps to light up and then light and extinguish two or three 
more in the course of the operator’s involvement on the call. For coin 
calls, part of the numerical display will also be lighted, showing the 
charge and initial period interval for each call. 

In summary, the console contains all the lamps, lamp drivers, 
memory cells (flip-flops), and overall controls to turn on and hold on 
the various combinations of lamps required for each call. It contains 
the circuitry to encode up to 84 keys in a 3-out-of-9 format for the 
scanner. It also contains duplicated input (signal distributor) and 
output (scanner) capability and the ability to permit input orders to 
generate output codes directly, with no operator present, for diagnostic 
purposes. 


2.5 Voice circuits 


Although the pci data lines are voice-grade circuits, they are used 
to transmit only data between the base and remote locations. Other 
voice-grade circuits provide connections between the RTA trunks and 
the base office (base-remote trunks), provide for operator talk paths 
(for PSs No. 2), and also connect the remotely located maintenance 
teletypewriter to the base location. Standard 4-wire voice-grade cir- 
cuits are needed for base-remote trunks, and any type toll-grade carrier 
system with groups of either 12 or 24 circuits may be used. 

For reliability, maximum diversification in the carrier groups, in- 
cluding a spare group, is required. This means that the carrier groups 
should be evenly distributed over two or more carrier route facilities 
and, within a route, the carrier groups should be distributed as much 
as possible over independent terminal equipments and power supplies. 

Carrier transfer circuitry is provided at the base and remote locations 
to switch the spare group into service in place of any other group that 
fails. Switching is controlled by a program at the base location which 
requires carrier group alarm signals as an input. Since there is only 
one spare group, loss of more than one carrier group results in partial 
facility loss and possible delays in handling calls from that RTA. 
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iil. RTA OPERATIONAL SOFTWARE IMPLEMENTATION 


When it was first proposed, the RTA operational software was visu- 
alized as being relatively straightforward. At the very beginning of an 
RTA call, a pair of base-remote trunks would be seized and used to 
“extend” the remote trunk to the base network. The appearances of 
the base-remote trunk would be arranged to be the software equivalent 
of those of a base universal trunk. Thus, throughout the succeeding 
stages of the call, the existing TSPs operational software® could be used 
without significant modification until, when the operator was released, 
the base-remote trunks would be disconnected and idled. 

Early in the planning, however, it was realized that this was not 
feasible. Not only was it uneconomical to leave both base-remote 
trunks up throughout the early stages of a call, but economics also 
dictated that trunk supervisory states be sensed and controlled via the 
PcL rather than by sensing and controlling the state of base-remote 
trunks. Moreover, the technology and complexity of the RTA trunks 
(see Section 2.3) caused the sequence of orders required to control 
them to be wholly different from that of base trunks so that the 
software which constructs trunk orders for base trunks could not be 
used. Also, the structure of the TSPs operational software did not allow 
the type of changes required for RTA call processing to be made simply 
or in a small number of low-level modules. 

The result was that the RTA operational software design was forced 
to evolve away from the initial concept of a few relatively large new 
modules with most of the existing operational software left intact. 
Instead, many small changes had to be made to most operational 
programs in the system. These changes were inserted at points where 
a position or service circuit is connected or released and at points 
where trunk control orders are formulated. Typically, the changes 
involved the addition of a software switch based on a test of the 
location (base or RTA) of the trunk under consideration. This test is 
facilitated by bits at several points in the trunk parameter register 
which have a value of 1 if the trunk is an RTA trunk and 0 otherwise. 
If the trunk is at the base, the switch directs execution of the previously 
existing program code. If not, a new RTA program leg is used to handle 
the call. 

Thus, most RTA operational software is relatively straightforward 
and will not be discussed further. However, several program areas are 
new to RTA and have no analog in the previous TSPS software. These 
include the control of the RTA concentrator, the base-remote trunk 
queuing structures, the “virtual” scanner used to maintain the state of 
remote trunk supervisory scan points, and a new type of audit. Each 
of these is discussed in the following sections. 
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3.1 Concentrator control 


During a normal Tsps call, various connections must be made to 
positions and service circuits. If the call is on an RTA trunk, such a 
connection requires the selection of: 


(z) An idle base-remote trunk and an idle path from the RTA trunk 
through the concentrator to that base-remote trunk and 

(it) An idle position or service circuit and an idle path through the 
TSPS base network from the base-remote trunk to that position 
or service circuit. 


Ideally, the path selection routine should hunt both (i) and (iz) 
simultaneously in one unified procedure. Such a procedure would be 
very complex because it would have to consider the RTA concentrator, 
the set of base-remote trunks, and the base network as one large, 
complex, six-stage network (two stages at the RTA and four at the 
base). However, since the probability of success on (ii) is virtually 
independent of the choice made on (i), little effectiveness is lost by 
hunting the path sequentially: first selecting (7) and then (ii). This 
allows one potentially complex single procedure to be replaced by two 
simpler sequential ones. The first of these is handled by the Concen- 
trator Control program—a new program for RTA—while the second is 
the previous Network Control program with slight modifications. 

Also used with slight modification is the path memory annex regis- 
ter,° which is linked to the call register during a network connection. 
It is used to store the identity of the connected circuits, and the paths 
used, their states, and, in the case of RTA, the concentrator paths and 
base-remote trunks used and their states. 

The Concentrator Control program is a subroutine capable of hunt- 
ing, connecting, and breaking paths from rRTa trunks through the 
concentrator to the base via base-remote trunks. It has an interface 
with the other call processing programs which is similar to that of the 
Network Control program. Like the latter, it has a set of linkage maps, 
shown in Fig. 8, which are used in the calculations. 

Conceptually, hunting and selecting a path for a call through the 
RTA concentrator, like any connecting network, may be done in two 
steps: 


(zt) Find all idle paths from the concentrator inlet of a specified RTA 
trunk appearance to the base network. If no idle paths exist, the 
call is said to be “blocked.” By “idle path” is meant a combi- 
nation of an idle base-remote trunk and an idle link connecting 
the trunk stage switch containing the inlet to the base-remote 
stage switch containing the base-remote trunk. 
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Fig. 8—Concentrator maps. 


(tt) Select one of these idle paths to be used for the call. The 
procedure used to do this is called the “routing procedure.” 


The choice of a routing procedure is important because it affects the 
blocking probability of the network—the probability that the call is 
blocked at step (1) above— and hence the amount of traffic that the 
network can carry. One requirement of a routing procedure is that it 
equalize the long-term mechanical wear of the network crosspoints. 
Thus, a good routing procedure will minimize network blockage while 
equalizing crosspoint wear. 

An unusual feature of connecting networks such as the RTA concen- 
trator is that none of the routing procedures commonly used for other 
networks, such as random selection (which is presently used in the 
TSPS base network) or packing (which is used in the No. 5 and other 
Crossbar Systems), is a particularly good choice. However, it may be 
shown’ that a near-optimal routing procedure is to select the path 
which goes through the base-remote stage switch which contains the 
largest number of idle base-remote trunks (with ties broken at ran- 
dom). The base-remote trunk to be used should also be selected at 
random. Studies show that use of this procedure increases the traffic 
capacity of the group of base-remote trunks by up to 3/4 Erlang at the 
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engineered load (about 40 Erlangs for a typical, large RTA) compared 
to the random routing procedure. This means that one less base- 
remote trunk is typically required—a substantial saving. 

The actual implementation of the path hunting procedure integrates 
the two steps above into one algorithm. First, a test is made to see if 
all base-remote trunks are busy. If they are, the call is placed on one 
of the base-remote trunk queues as described in the next section. If 
one or more base-remote trunks are idle, the routine reads the proper 
link busy/idle word from the link map (Fig. 8) and forms the logical 
product of it with word n of the relative busyness map for n as small 
as possible such that the result is nonzero. A binary search is used to 
quickly find the proper value of n. If no such n can be found, the call 
is blocked. If the call is not blocked, then one of the I’s in the result is 
selected at random, the corresponding word of the base-remote trunk 
map is read, and one of the |’s in it is selected at random. The two I’s 
which are selected determine the path to be used by the call. To 
connect the path, the program loads the appropriate concentrator 
control orders in an output buffer, updates the concentrator maps, 
writes the path information into the path memory annex, and then 
terminates. 


3.2 Base-remote trunk queuing 


With RTA, a new group of hardware resources, namely base-remote 
trunks, is added to the TsPs system. One of these resources is routinely 
applied to a call at the same time as other resources such as operator 
positions and service circuits. In addition, on some calls, a connection 
must be made to two base-remote trunks at the same time (on dial-0, 
dial pulse, non-ANI calls, for example). And most calls have two base- 
remote trunks up simultaneously at some point in the call (for position 
and outpulser). Although the normal engineering of these relatively 
expensive resources is adequate, the supply may be cut in half by an 
outage of one of the two diverse routes which the base-remote trunks 
traverse. Since the base-remote trunks are normally engineered near 
or over 50 percent occupancy, such an outage can instantly throw the 
RTA into heavy overload. Although rare, this condition is the most 
likely rTA failure state because of the excellent reliability of the rest of 
the equipment. 

These facts imply that the group of base-remote trunks must be 
carefully administered. Also, it was desirable to cleanly integrate the 
queuing for base-remote trunks into the existing TSPS queuing struc- 
tures which, although they are basically quite powerful and flexible, 
have the built in assumption that only one resource may be queued 
for at a time. 

The solution chosen is to have two first-come, first-served base- 
remote trunk queues served in priority order for each RTA. 
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If all in-service base-remote trunks are busy, calls wait in one of 
these queues. When a base-remote trunk becomes idle and available 
for use, it is connected to the first call on the high priority queue. If 
there are no calls waiting on the high priority queue, the base-remote 
trunk is connected to the first call on the low priority queue. 

Generally, if no base-remote trunks are available the first time in a 
call when one is needed, the call waits on the low priority queue. 
Thereafter on that call, the high priority queue is used whenever base- 
remote trunk congestion is encountered. 

This structure has several advantages. First, it gives priority to calls 
already in the system on which considerable system resources and real 
time have already been invested. Also it fits well into the existing “one 
resource per queue” TSPS queuing structure. For example, if a call 
needs two base-remote trunks at the same time and none are available, 
the call waits on the low priority queue until it gets one. Then it waits 
on the high priority queue and it will get the very next base-remote 
trunk that becomes available (the fact that it received one base-remote 
trunk while on the low priority queue means the high priority queue 
was empty). Thus, the call gets two base-remote trunks in slightly 
more than one waiting time. 

Under conditions of RTA overload (caused by, say, a traffic overload 
or a route outage affecting up to half the base-remote trunks), simu- 
lation studies show that the low priority queue can become quite long 
while the high priority queue remains very short, usually with either 
zero or one call in it. In this case, every RTA call waits in the low 
priority queue exactly once, and thereafter uses the very short high 
priority queue. The result is that every call receives a roughly equal 
grade of service no matter how many base-remote trunks it needs 
during its course. (It is impossible for the high priority queue to 
become very long in the steady state, for if it were to become long, 
then the low priority queue would never be served and no new RTA 
calls would ever get into the system—a contradiction.) 

The same simulation studies show that, with this queuing structure, 
the probability of deadlock is extremely low. An example of deadlock 
is as follows. Consider an idle RTA with N in-service base-remote 
trunks. Suppose that exactly N dial-0 calls arrive nearly simultane- 
ously. Each would be connected to an operator using a base-remote 
trunk, thus making all such trunks busy. Each operator would then 
key in the called number and attempt to initiate outpulsing. Since 
outpulsing requires a second base-remote trunk, all N calls would be 
loaded onto the high priority queue. Since no base-remote trunks are 
available, all N calls will be deadlocked until one of the operators or 
customers abandon. Because the probability of this occurring was 
determined to be very low, no defensive measures have been added to 
the programs. 


RTA HARDWARE AND SOFTWARE. 1191 


The programs seek and obtain a base-remote trunk for a call, 
queuing if necessary, before attempting to obtain a position or service 
circuit. Since positions are a more expensive resource, the base-remote 
trunk normally remains connected to the call throughout any position 
queuing to avoid adding the time required to queue for and connect 
the base-remote trunk to the operator work time. Thus the position 
queuing time is added to the base-remote trunk holding time. Because 
this has the potential to translate an operator overload into a base- 
remote trunk overload, a complex overload procedure is utilized which 
disconnects the base-remote trunk from the call if the position queue 
is very long and uses the high priority queue if necessary to reobtain 
one quickly. 


3.3 The virtual scanner 


The TSPs programs often determine the supervisory state of a trunk 
by directly scanning it. This cannot be done with RTA because the RTA 
scanner is autonomous. To solve this problem, a software image of the 
state of each trunk scan point is maintained in temporary memory. 
This is called the virtual scanner, since the required directed scans can 
be done by “scanning” (a memory read) this area of memory. 

It is implemented by adding a virtual scanner (vs) bit to the two 
bits already assigned to each scan point® (one of these gives the last 
reported supervisory state while the other indicates that reporting 
supervisory changes has been temporarily suspended on this trunk). 

The vs bit represents the software’s best estimate of the current 
state of the scan point and is always updated whenever a trunk 
supervisory state change report is received from the RTA. 

The only complication occurs when an RTA initialization is required. 
Such an initialization leaves talking state RTA trunks intact, but idles 
all others. Often when this happens, the information in the virtual 
scanner is probably unreliable so that the state of the trunk is no 
longer considered known. 

When this occurs, charging is canceled on all RTA talking calls at the 
time and the RTA trunks are put into a special software “limbo” state. 
This state means that the software does not know whether the trunk 
is idle or talking. When an on-hook report is received on a limbo state 
trunk, the software assumes the trunk was in the talking state and 
initiates disconnect actions. Conversely, if an off-hook report is re- 
ceived, the trunk is assumed to have been idle and initial seizure 
actions commence. 


3.4 Audits 


The existence of the virtual scanner required a new type of audit 
program called the “virtual scanner update program” which is quite 
different from other system audits. 
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Normally, system audits are run on a routinely scheduled basis. 
Their purpose is to check the integrity of the software data structures. 
The virtual scanner update, however, is designed to check the consis- 
tency of the virtual scanner with the hardware state of the trunks. It 
does this by sending out a sequence of special orders which cause the 
trunk to send back several reports which together indicate its current 
state. Since doing this on all RTA trunks could overload the PCL, it is 
done very slowly over several minutes. When it is complete, an output 
message is printed, stating the number of errors found. 

The audit is normally run during off-peak night-time hours and is 
used to verify the integrity of the virtual scanner and resolve any 
limbo state trunks which may exist at that time. It is also run after 
certain rare types of fault recognition activity which cause the scanner 
word buffer to be initialized with the possibility that one or more RTA 
trunk supervisory reports may be lost. 


IV. RTA MAINTENANCE PLAN 


Reliability requirements for an RTA subsystem have been set to meet 
the overall objectives of a Tsps No. 1 system: less than 2 hours 
downtime per 40 years service and less than one mishandled call per 
10,000 calls. The maintenance plan for RTA is further influenced by the 
fact that an office is frequently unattended and may be located 
hundreds of miles from the base TSPS. 

Sections 4.1 and 4.2 discuss PCL error detection as implemented in 
the hardware and software, respectively. Remote diagnostics are cov- 
ered in Section 4.3. Section 4.4 deals with initialization of RTA circuits, 
while Section 4.5 describes trunk test capabilities for RTA. 


4.1 PCL error detection (hardware) 


The Pci data lines may be subjected to errors from a variety of 
causes. To aid in detecting multibit errors which result in single word 
errors, each word transmitted is encoded with a 5-bit cyclic error 
detecting code and a parity bit. In addition to single word errors, 
multiword errors on a data line may occur as a result of hits and fades. 
Each word error within a multiword error is treated separately by the 
group gate and remote data circuits. As a result, single and multiword 
errors are handled similarly. 

As mentioned previously, the group gate and the remote data circuit 
send data to each other over a data line. An error detected by the 
receiving circuit must be reported back to the sending circuit so that 
the word can be transmitted again. This is accomplished by a verifi- 
cation system whereby a “scan-complete” is used to acknowledge a 
report received by the group gate, and a “check-back” acknowledges 
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a properly executed order received by the remote data circuit. If an 
acknowledgment is not received, the word is retried until it succeeds 
or the retry limit is reached. 

A system requirement of RTA is that the voice circuits and data lines 
may use any transmission facility. This means that the Pci data lines 
must be able to operate over voice-grade circuits that have a relatively 
slow data transmission rate. Because of this and the distance (several 
hundred miles) between base and remote locations, about 45 ms are 
required to verify that an order or report has been sent without error. 
Since a PCL data rate of one order every 25 ms is required to deal with 
momentary call processing peaks and to allow use of as many existing 
tsps No. 1 programs as possible, an overlap operation is employed. 
This means that, before verification of the first word is received, the 
second word is sent. If an error is detected, the receiving circuit 
discards both it and the succeeding word. The sending circuit retrans- 
mits both words if it doesn’t receive verification of the first word. 
Therefore, the group gate and remote data circuit are designed to 
retain information about the last two words sent in case repeat trans- 
missions in either direction are necessary. The overall maintenance 
strategy is strongly influenced by this aspect of the PCL. 

The pct hardware can detect errors other than transmission failures 
that would be seen by parity or cyclic code check failures. These faults 
are classed as “send” or “receive” direction faults. The former type 
will be discussed first. 

The normal mode of PCL operation requires that each pcu half 
independently handle a processor order until it has been received at 
the remote location by the remote data circuit for each half. The two 
remote data circuits then compare the orders and if they match, one 
PCL half (a so-called ‘‘active” half) actually distributes the order to a 
trunk, concentrator, etc. If one half has a “good” order and the other 
half has received nothing or has a transmission failure, then the half 
receiving the good order becomes the active half and distributes the 
order. This mechanism, known as Full ored Mode, is intended to 
reduce order retries due to data line transmission errors. 

Each time the processor sends an order via the PCL to the remote 
location, the buffer which is to handle the order generates a checkback 
report as verification. This checkback is returned to the processor as 
an indication of correct operation; its absence indicates unsuccessful 
operation. The use of checkbacks allows for detection of faults beyond 
the signal distributor but only partly through the RTA buffers; the 
actual operation of relays and crosspoints are not verified by check- 
backs. Those failures which occur beyond the checkback origination 
point are detected by error analysis programs. 

- Due to the overlap operation of the Pct described above, the remote 
data circuit is designed to also fail the order arriving after an order 
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which results in a checkback failure. This ensures that the second 
order is not executed before the first, necessary because the second 
order may depend upon the success of the first order and might lead 
to a mishandled call if the first order is unsuccessful. 

The receive direction faults are those pertaining to the reception of 
signals originated by RTA circuits. The detection of these faults depends 
primarily on mismatches between PcL halves. Normally, the two PCL 
scanners each detect a change of state of an RTA circuit point and 
generate a report. These two reports are passed back to the group 
gates where they are compared. Subsequent to receiving the reports, 
the group gates transmit “scan-complete” words to the remote data 
circuits so that another pair of reports can be sent to the base. 

In addition to matching, however, a cyclic code check is made, an 
all-seems-well indication from each scanner is checked, a parity check 
is made, and a sequence code check is made in each report received. 
The cyclic codes are inserted into the report by the remote data circuit; 
the all-seems-well, parity, and sequence indications are generated in 
the scanner. Cyclic codes and parity have been described earlier. A 
sequence code occupies two bits in each report and is used to eliminate 
redundant reports received at the group gate. This typically occurs 
when a “good” report is received but the scan-complete signal fails, 
causing an unnecessary retransmission of the report by the remote 
data circuit. If the sequence code check fails, the report is discarded 
by the group gate. The all-seems-well signal is generated by self- 
checking circuits within each scanner, as described in Section 2.1.2. 

With both pct halves in service (duplex), one group gate is desig- 
nated as active. If a mismatch occurs and the active half has a “good” 
report (one which has correct cyclic code, parity, sequence, and all- 
seems-well), while the other half has received nothing or has a trans- 
mission failure, the good report will be passed on to the processor. 
However, if the active half has received nothing or has a transmission 
failure while the other half has a good report, a null scan-complete is 
generated, causing the report to be retransmitted. This mechanism, 
known as Half ored Mode, takes into account the fact that the active 
group gate controls the matching. (If the program determines that 
only the active half has a transmission failure or has received nothing, 
it simply changes the designation of the active half to the one receiving 
the good report, leaving the PcL in duplex mode.) 

In accordance with the circumstances described above, a group gate 
mismatch results in automatic retransmission of reports. However, if 
the group gates continuously mismtach several times, the PcL fault 
recognition program will take action to resolve the mismatch. The 
tolerance for a few mismatches allows the PcL to automatically recover 
from a momentary transmission impairment affecting one of the data 
lines. 
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Many faults can occur in the scanners which can only be detected 
by matching. The key characteristic of these faults is the presence of 
two apparently valid but different words that repeatedly mismatch. 
The cause of this is either the generation of an extra word or the lack 
of a generated word in one of the scanners. Under these circumstances, 
the list of reports in the two memories of the scanners become skewed 
and a mismatch occurs. The mismatching words represent two scanner 
inputs, one of which is faulty. This situation is handled by the “receive 
chain” fault recognition programs, which are discussed in the next 
section. 


4.2 PCL fault recognition (software) 


As described in the previous section, the PCL circuits have been 
designed to detect and correct for most errors which are the result of 
transmission impairments of short duration. For longer hits, fades, and 
PCL circuit failures, various other hardware indications, such as check- 
back failures and group gate alarm ferrods, allow PcL fault recognition 
programs to maintain working send and receive chains. The send chain 
refers to those circuits involved in the distribution of a PCL order: the 
group gate, remote data circuit, signal distributor, and the PcL buffers. 
The receive chain refers to those circuits involved in the reception of 
a PCL report: the group gate, remote data circuit, and position and 
trunk scanner. 

If an order has been retried on a duplex PCL without the reception 
of two successive check-backs for 0.5 second, the send chain fault 
recognition program will be entered. When this occurs, call processing 
is suspended and a special test order is sent to an independent buffer. 
If that order is executed successfully, the original buffer accessed is 
deemed faulty. If the test order fails, the program splits the PCL so 
that each pc half is completely independent with no matching taking 
place. The resulting simplex operation allows the original failing order 
to be tried first on one and then on the other PcL half. If the order fails 
over both halves, the program tries a second test order (to a different 
buffer) over each half. Based on the results of these tests, the program 
decides which half is faulty and places that PcL half out of service. 
Normal call processing is resumed on the good half, and diagnostics 
are run on the out-of-service half. 

For receive chain faults, the fault recognition programs are entered 
whenever an error rate monitor (administered by software) corre- 
sponding to a group gate alarm ferrod exceeds its threshold. The 
absence of either all-seems-well, good parity, or proper sequence on a 
PCL half automatically indicates the faulty half. Mismatches between 
two valid reports involve more detailed processing. 

Due to the overlap operation of the PCL, two reports on each half 
are sent to the base during retransmission. In the case of skewed 
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reports, chances are that two of the reports received match; that is, 
one of the reports received on one half may match one of the reports 
on the other half. The receive chain program checks for this case to 
eliminate the need for testing all four reports. Only those reports seen 
by only one half are further tested. 

When the receive chain fault recognition program is entered, call 
processing is suspended. The PCL is again split into two simplex paths 
and a bypass in the scanners is activated to allow test results to be 
sent back to the base without disturbing the scanner word buffers. 
Each scanner is then checked, via test points, for the ability to generate 
the reports to be tested. These test results are analyzed by the program 
to determine which Pct half is in trouble. The faulty half is placed out 
of service, and diagnostics are run on it. Call processing resumes on 
the in-service half. The flow of reports proceeds from where it was 
interrupted, with the PcL in the simplex mode. While in the simplex 
mode, subsequent faults of this type go undetected. 

In general, fault recognition program actions are transparent to call 
processing programs. In the case of a PCL mismatch, the original 
reports are retained in processor memory so that, once it is determined 
which PCL half is faulty, the reports already received on the good half 
can be passed to call processing programs. As already mentioned, the 
PCL scanners contain word buffers that can retain up to 31 reports 
which may have occurred while fault recognition tests were being 
applied. This is sufficient memory to handle a back-up of reports 
caused by fault recognition activity in all but the very worst cases. 

In addition to the send chain and receive chain fault recognition 
programs, the data line fault recognition program responds to trans- 
mission errors reported to the spc. Error rate monitors, driven by the 
group gate alarm ferrods, are maintained for each connected data line. 
When the allowable error rate is exceeded, the line that appears to be 
faulty is replaced by the spare line. After a delay of a few minutes, the 
apparently faulty line is reconnected. If its error rate is acceptable, no 
further action is necessary. If it fails again, however, the spare line is 
used until the faulty line is repaired or has been determined by 
subsequent automatic tests to have recovered. The spare data line is 
also used periodically so that its operational status can be monitored. 

The state of the data lines must also be considered by the fault 
recognition programs when reconfiguration is being performed. If all 
circuits on a PCL half are working but both data lines that can connect 
to it are out of service, then that PcL half is not usable. 

Although the normal mode of the PcL is the duplex mode, it is 
possible that a fault could occur while the PCL is simplex. The PcL 
could be simplex because diagnostics are being run on the out-of- 
service half or because a circuit on that half is inoperable. If the fault 
recognition program determines that the active half has a circuit in 
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trouble while the PcL is in simplex, the out-of-service half will be 
placed in service and the active half removed from service. 

In cases where the out-of-service pcL half is already marked in 
trouble or has been manually made unavailable to fault recognition 
and a fault has also been detected on the in-service half, no known 
working path of PCL units exists between the base and remote locations. 
Rather than to place the entire PCL out-of-service, a special fault 
recognition program is invoked which attempts to find a working path, 
regardless of the software status of the units. This program systemat- 
ically tests both the send chain and the receive chain of the PcL by 
using test orders and different combinations of data lines and base 
peripheral circuits that interface the processor to the group gates. In 
the event that these tests fail, the PcL will then be placed out of 
service. However, the program will automatically retest the PCL every 
few minutes and restore it to service as soon as one working (simplex) 
path is found. Because the duplex state offers maximum error detec- 
tion, an out-of-service PcL half is also automatically tested for the 
absence of units in trouble (or a manual request to leave the half out 
of service) when the PCL is simplex. If no reason for the simplex 
configuration is found, the pcu will be restored to the duplex mode. 


4.3 Remote diagnostics 


The long data paths to RTA and pss No. 2 installations and the desire 
to use voiceband facilities resulted in the use of 2400 b/s data rates 
between the spc location and the remote locations. If lengthy strings 
of diagnostic tests were run from the SPC over an in-service PCL half to 
locate a trouble in the other (bad) Pct half, then call processing would 
be virtually halted for the duration of the diagnostic. To prevent such 
adverse call processing effects and still allow thorough diagnostics, the 
entire set of diagnostic test sequences are placed at the remote end 
and controlled by a diagnostic control circuit (DCC) which, in turn, is 
controlled by the spc. The concept of placing the diagnostics at the 
remote location provides two other very desirable operations as well 
as minimizing adverse call processing effects. It allows the tests to run 
very fast since no transmission time is involved, and it allows the pcc 
to have direct access to various internal points of the circuits being 
diagnosed which would otherwise be impossible to obtain. With the 
exception of the scanner with its need for 25 ms to recognize a change 
of state (see Section 2.1.2), diagnostic orders can run at least an order 
of magnitude faster than regular Pct orders. This significantly reduces 
the time between a request for a diagnostic and TTY output of results. 

The pcc is essentially a very low-level minicomputer with sequences 
of tests and expected results of those tests stored in Read-Only- 
Memory (ROM). Each Rom word is 24 bits long and contains a 3-bit 
operation code (op code), 20 data bits, and a parity bit. The data bits 
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usually apply a set of test conditions to a PCL circuit and cause that 
circuit to take some action. A subsequent ROM word contains an 
expected result which is matched against the actual result. If the result 
agrees, then another test word is selected from ROM and the process 
continues. The access that the pDcc has to the various PCL circuits is 
shown in Fig. 9. Note that indirectly the Dcc has access to all remote 
circuits; e.g., although it has no direct connection to a 100C console it 
can send orders to the RDc which can cause the signal distributor to 
send an order to a console. Similarly, while it has no input from a 
console it can check the scanner output to see if the scanner received 
a console output. 

When comparisons of actual and expected results fail, a reply (noting 
the failure) is sent back to the spc over the in-service PCL half. 
However, if massive failures are encountered, this reply capability is 
limited, so as to limit its effect on call processing. Also, massive failures 
will cause the spc to terminate the diagnostic early since they quickly 
pinpoint a source of trouble. Whether or not comparison failures occur, 
every 64th Rom word causes a “progress report” type reply to the spc 
to inform it that the diagnostic is continuing. The “failure report” sent 
back to the spc on all mismatches provides a number between 0 and 
63. The first 64 words of ROM store these 64 possible failure reports. 
The action taken by the pcc when a comparison failure (expected 
result versus actual result) occurs is to just set all but the least 
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Fig. 9—pcc access to PCL circuits. 
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significant 6 bits of the address counter to zero. The next ROM word 
selected will then be one of the first 64 words and as this reply is sent 
back to the spc and upper address counter bits are unclamped. With 
all address counter bits operational, the next word selected is the next 
word in the diagnostic test sequence. Thus no real program transfer 
and return function is needed in the Dcc since this hardware approach 
to changing the address counter output does the transfer job and 
automatically includes the correct return condition. 

The spc controls the pcc by three steps. First, an order is sent over 
the inservice PCL half to place the out-of-service half RDc in the 
diagnostic mode, i.e., connect it to the pcc. Second, an order is sent to 
the pcc (again, over the in-service PCL half) to preload the desired 
starting address into the pcc address counter. Finally, a “start” com- 
mand is sent to the pcc to select the first Rom word (at the starting 
address). This first word of any diagnostic sequence is always an “SPC 
reply” type word that returns the starting address to the spc. The spc 
checks this against the desired starting address and stops the bcc if 
the return is incorrect. 

Since the spc knows the starting address and is informed when every 
64th subsequent address is reached, it can quickly compute the exact 
location of a comparison failure (its location in that diagnostic se- 
quence) whenever it receives a failure report with its 0-63 tag number. 
Thus at the end of a diagnostic sequence, the spc has a pattern of 
failures and uses these to generate a “trouble number.” This number 
is then compared to a trouble dictionary to locate the failure. 

The overall access which the pcc has to each remote RTA circuit can 
be understood by looking at the 8 possible operation codes together 
with the expansion of one such operation code. The 8 operation codes 
(op-codes) are listed below. This listing also gives the reader a glimpse 
at the Dcc programming possibilities and indicates the ease with which 
each RTA circuit designer could write the appropriate diagnostic. 


000 8-bit comparison or 25-ms delay 

001 20-bit comparison from RDC 

010 rpc test vector (DCC output) 

011 20-bit scanner comparison preceded by 25 ms delay 
100 Signal distributor test vector (DCC output) 

101 20-bit comparison from signal distributor 

110 Rbpc test vector (DCC output) 

111 spc reply word (Dcc output) 


The 000 op code is expanded within the 20-bit data field since only 
eight of the data bits are actually needed for an 8-bit comparison. The 
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order has the form: 


23 22 15 11 6 2 0 
P Zz Ze Zs Zs Zz Z2 Z1Zo 111 C/D X3 X2 X11 MCBA 000 











where 
Bits 0 to 2 are the op code (000). 
CBA = 3 bits used to select the particular 8-lead input desired. 


B A Compare Input 


Input from signal distributor 
All ones input 

Input from RDC 

Input from scanner 

Spare input set Y 

Spare input set X 

Input from Dcc 

1 1 All zero input 


M = “Mask” bit used to insert 1-bit mask. If M = 1, no mask is 
used and all 8 bits specified by CBA are compared against 
Z; — Zo. If M = 0, a 1-bit mask is enabled as specified by 

. the X3X2X1 bits. 

X3X2X, = Mask selection bits used to specify which of the 8 input 

leads are to be compared. 

Compare/delay bit used to differentiate between use of 

this order for 8-bit comparisons or for 25-ms delay intervals. 

Z7 — Zo = 8 comparison bits. 


FPR eE rR OOOO D 
—-H OOrR FH COO 
Se Of Or 


C/D 


The other seven op codes perform only the function listed and all 20 
data bits are either applied by the Dcc as a test vector or used by the 
bcc for a comparison. 

The op code listing together with the 8-bit comparison possibilities 
shown above indicate the large number of internal points of all remote 
PCL circuits to which the pcc has access. The Dcc concept allowed 
diagnostic points to be placed where they would do the most good. 
This makes every test/comparison pair of orders a powerful pair and 
leads to short diagnostic phases. These short phases together with the 
fast execution times allow most diagnostics to complete in a few 
seconds. As the diagnostic completes one phase (and before it starts a 
subsequent phase), a few spc orders can be sent out to reconfigure the 
PCL half under test. For example, the RDC can be configured to loop 
back on itself. The pcc can then send orders to the scanner input side 
of the RDC—similar to reports normally returned by the RDC to the 
spc—and, since the RDC is looped, these orders will come right back 
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through the receiving half of the Rpc. They can then be examined by 
the pcc or allowed to continue to the Signal Distributor and cause 
some action there. Again, at the Signal Distributor, the test vector can 
be examined by the pcc or allowed to propagate even further and 
cause some other action further downstream. Judicious use of such 
pcc comparison tests allow very thorough diagnosis of remote circuits. 

The bcc also has inputs from itself as well as all 1 and all 0 type 
inputs. It can use these inputs to run tests on itself and inform the spc 
of possible pcc troubles. Massive failures in other circuits usually 
trigger (via an SPC program decision) this self-test of the Dcc to ensure 
that the massive failures are real and not just the result of an inability 
of the pcc to make comparisons. 

The pcc currently uses about eleven thousand 24-bit ROM words to 
test out all remote PCL circuits. The memory layout provides three 
circuit pack locations, each of which can contain 8K (K=1024) words 
so the memory can grow to 24K words if needed. The upper 16K 
addresses are also available in eight other circuit pack locations, each 
of which can accommodate a 2K-word PROM circuit pack. With this 
arrangement, the memory can be placed on ROMs on 1-1/2 circuit 
packs. Then, as various remote PCL circuit changes and additions take 
place which would tend to degrade the original diagnostic effectiveness, 
new versions of selected diagnostic phases can be placed in PROMs on, 
say, one new memory board plugged into a PROM circuit pack location. 
A 1-word change in the spc program can then be used to specify a new 
starting address for the affected phase (or phases). The old version of 
the diagnostic is still there, but never gets used while the new (higher 
numbered) starting address selects that one phase from the PROM 
board. As PROMs are added over a period of years, and several sections 
of the original (ROM) program become unused, the ROM can then be 
redone to reflect several years of change. 


4.4 RTA initialization 


The RTA maintenance buffers contain a variety of distributor points 
used in conjunction with the operation of several remote circuits. 
When pc. reconfigurations occur, either by manual request or as a 
result of fault recognition action, some points in each buffer must be 
cleared. Some points are used to initialize the remote data circuit, 
signal distributor, and position and trunk scanner. Each buffer also 
contains points not connected with a particular pcL half which should 
not be cleared when reconfiguration takes place. To achieve the desired 
results, each maintenance buffer has been functionally divided such 
that selective initializations of these buffers can be performed. The 
selective initialization feature of the maintenance buffers also provides 
the capability of regenerating the PcL status display at the remote 
location upon manual request. In addition to the selective initialization 
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leads, each maintenance buffer is equipped with a lead which clears all 
points in the buffer. These leads are pulsed only when the entire PcL 
is being initialized, such as when a system initialization occurs, or when 
the PcL has developed faults on both halves. 

Under certain circumstances (e.g., RTA or TSPS system initialization), 
it is desirable to place all the remote and base-remote trunks in an idle 
state. Since the number of remote trunks (496 max) and base-remote 
trunks (64 max) in an RTA may be large, individual trunk initialization 
would be very time-consuming. The trunk super-initialization feature 
of RTA allows all the remote trunks to be initialized with two orders 
and all the base-remote trunks to be initialized with one order. This 
allows for speedy initialization of the RTA trunks when necessary. It 
should be noted that those trunks already in the talking state will not 
be affected by the super-initialization orders. 


4.5 Test frame capabilities 


The test frame at the remote location displays status information 
and provides control and test facilities including a maintenance tele- 
typewriter. As shown in Fig. 10, the out-of-service status lamps for the 
PCL equipment are physically arranged to depict the equipment ar- 
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Fig. 10—Ppcu and voice status displays. 
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rangement in block diagram form. The three data lines are represented 
by three rows of light-emitting diodes which, when lit, indicate active 
working routes. The sw 0, SW REL, and sw 1 keys in the status display 
enable the remote ends of the data lines to be switched. This capability 
is provided to allow manual intervention in the rare case that both 
active data lines fail before the maintenance program at the base 
location has the opportunity to order the remote equipment to switch. 

Several trunk test facilities are provided on the test frame as 
indicated in Fig. 11. A Dial Access Test Line (DATL) permits local 
office personnel to check transmission and noise levels on incoming 
trunks between the local office and the RTA without requiring assist- 
ance at the RTA. The Master Test Line (MTL) permits RTA personnel 
to establish voice communication with any trunk that terminates on 
the concentrator. The access line permits any trunk to be connected 
to any one of the test frame facilities which include a voltmeter, 
transmission level and noise measurement apparatus, a variable fre- 
quency milliwatt supply, and a quiet termination. 

The test frame voltmeter and transmission measuring devices have 
a digital readout capability. The measurements can be remotely read 
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by the base program and printed on the base location maintenance 
teletypewriter. This permits detection, verification, and sectionaliza- 
tion of many trunk problems without anyone present at the RTA. 
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Traffic Service Position System No. 1: 


Automated Coin Toll Service: 
Overall Description and Operational 
Characteristics 


By M. BERGER, J. C. DALBY, Jr., E. M. PRELL, and V. L. RANSOM 


(Manuscript received December 11, 1978) 


Automated Coin Toll Service (Acts) has recently been developed 
for use on Traffic Service Position System No. 1. ACTS automates the 
handling of most calls paid for at coin stations, gives time and charge 
quotations, and provides customer notifications. To accomplish this, 
a new microprocessor-controlled subsystem is added to TsPps. This 
subsystem generates announcements and monitors coin deposits. 
Since ACTS reduces the operator involvement on coin toll calls, it 
achieves significant savings for the operating companies. ACTS was 
developed together with several other associated features. This entire 
package was first put into service in November 1977, in Phoenix, 
Arizona. This paper gives a functional description of the new subsys- 
tem and details the customer interface with acTs and the other 
features. 


|. INTRODUCTION 


To reduce the operating expenses associated with handling coin toll 
calls at a Traffic Service Position System (Tsps) No. 1,’ Automated 
Coin Toll Service (AcTs) has been developed. ACTS permits automated 
processing of (z) the initial contact on most station calls paid for at 
coin stations (station-paid coin calls), (iz) notification at the end of the 
initial period on all coin-paid calls, (zit) overtime charge-due seizure 
on most coin calls, (iv) the customer-requested notification on a call 
that is not coin-paid, and (v) the quotation on time and charge calls. 
This is accomplished by giving machine-constructed announcements 
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to the customer and by providing machine recognition of coin deposit 
signals. Thus, ACTS reduces the operator work time on coin toll, 
noncoin notification, and time and charge calls, and thereby achieves 
significant savings for the Bell System. 

The technology and concepts of Automated Coin Toll Service 
evolved over several years. First, the technical feasibility of AcTS was 
demonstrated in 1973 by building an exploratory model. System engi- 
neering studies were conducted in conjunction with American Tele- 
phone and Telegraph Company (AT&T) and the operating telephone 
companies that showed the reduction of operating expenses would 
offset introductory costs. Three parallel and interrelated development 
activities emerged. First, a new subsystem was added to Tsps. This 
subsystem, the Station Signaling and Announcement Subsystem 
(SSAS), uses a microprocessor called the Programmable Controller 
(PROCON) and semiconductor memory. The memory is loaded with 
speech segments that have been digitally encoded. The SSAs retrieves 
and concatenates these speech segments into sentences. By converting 
the bit stream to analog signals, SSAS can “speak” to customers. In 
addition, SSAS monitors coin deposits by the customer to determine 
when a coin deposit request is satisfied. Second, software and firmware 
were developed for the Tsps controller which is the Stored Program 
Control (Spc) unit’ and the PROCON, respectively. This software allows 
the TsPs to interface with the subsystem and the subsystem to perform 
the desired tasks. Third, because of the complexities of the new 
machine-customer interface, a human factors study was conducted in 
Chicago, Illinois. In this study, a sampling of coin customers was 
exposed to the proposed ACTS service, which was simulated from 
existing positions. This human factors simulation established wording 
and timing parameters used in the ACTs design. 

Part of the technical challenge was to introduce ACTs into live TSPS 
sites without interrupting the normal call-handling process. Not only 
was this challenge met, but additional features were introduced at the 
same time. These features include: 

(i) Expanded direct distance dialing to Mexico. 

(tt) Improved queuing strategy for calls transferred to Tsps for 
calling number identification for billing purposes (Centralized 
Automatic Message Accounting, or CAMA, traffic). 

(uz) Special automated procedures to better control overload con- 

ditions. 

(tv) The ability to more efficiently redistribute (rehome) TSPS 
trunks to different toll or local offices. 

(v) Increased coin station test capabilities. 

(vt) Other miscellaneous features. 

These features and acts were packaged as a version of TSPS called 
Generic 8. Following initial service in Phoenix, Arizona on November 


1208 THE BELL SYSTEM TECHNICAL JOURNAL, JULY-AUGUST 1979 


26, 1977, this generic was made generally available to the Bell System 
in mid-1978. 

This paper gives an overview of ACTs and some of the other features 
associated with Tsps Generic 8. It highlights the hardware and software 
associated with each feature. Additional details of the three develop- 
ment activities that culminated in ACTS are specified in later papers in 
this special issue.*” 


it. COIN TOLL SERVICE PRIOR TO ACTS 


TSPS provides a vast improvement in efficiency over cordboards in 
handling coin toll calls. Not only is the operator’s interaction with a 
customer more efficient and accurate but, in addition, Tsps allows coin 
customers to dial their own calls, thereby providing faster service. 

In a typical Tsps, between 10 and 15 percent of the calls handled by 
operators are toll calls made from coin stations and paid for with coins 
deposited at the station by the customer. On these calls in a non-AcTS 
TSPS, an operator is required (i) to quote to the customer the initial 
period length and charges, and to monitor the amount deposited, (iz) 
to notify the customer at the end of the initial period, and (ziz) to quote 
and collect charges due for overtime at the end of the call or after 10 
overtime intervals. To assist the operator in processing coin-paid calls, 
TSPS generally calculates the rates, automatically displays the charges 
at the operator position, and times the call. 

To better understand how the various functions described above are 
handled by an operator at a TSPs prior to the introduction of AcTs, the 
following details how TSPs processes a coin-paid call. Figure 1 shows 
the layout of the keys and lamps on the operator position. 


2.1 Initial period contact 


To place a station-to-station call at a coin phone served by a TSPS, 
a customer makes an initial deposit and listens for a dial tone. (In a 
dial-tone-first area, the initial deposit is not required.) As soon as the 
dial tone is obtained, the customer dials the digit one* plus the 
complete 7- or 10-digit called number. The local office determines that 
this call is a toll call and routes it over a trunk to its associated TSPS. 
TSPS receives the called and calling number from the local office and 
determines the charges on the call. The Tsps establishes the necessary 
connections through its network to bring the call to an operator 
position. While the operator is responding to the call, the called 
number is outpulsed to the toll office. 

The call arrives at the position with appropriate keys and lamps lit 
to indicate that this is a coin call. The station initial period charges 


* Some areas do not require the digit one to be dialed, depending on local number 
plan arrangements. 
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and minutes are displayed to the operator, as depicted in Fig. 2. The 
operator then requests the initial deposit from the customer and 
depresses the station-paid class-of-charge key to indicate to the system 
that a station-paid call is being handled. The customer then deposits 
the coins, and the operator monitors coin signals to determine if the 
proper deposit has been made. Meanwhile, the call is forwarded 
through the Direct Distance Dialing (DDD) network. 

When the customer deposits the correct amount, the operator ac- 
knowledges receipt of the deposit. Then, upon hearing the audible ring 
of the calling station, the operator prepares the system for automatic 
timing of the call after called party answer. This is done by depressing 
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Fig. 2—tTsps No. 1 console numeric display. 


ACTS: OVERALL DESCRIPTION 1211 


the start timing key. The operator then releases the position, conclud- 
ing the initial contact phase of the calls. 

When the customer does not deposit enough money, the operator 
requests the additional amount. If the call has not yet progressed 
through the DDD network, the operator stops the forward action of the 
call by depressing the release forward key. When a full deposit is 
received, the operator reinitiates the network connection by depressing 
the start key, then he or she depresses the start timing key, and 
releases the position. 

If a customer lacks proper change, he or she may deposit too much 
money. The operator acknowledges this overdeposit and instructs the 
customer to tell the operator that credit is due when overtime is 
collected. 

With the operator released to handle another call, TSPs times the 
call for the initial period. Before the end of the initial period, TsPps 
sends a signal to the local office to cause the initial deposit to be 
collected. 


2.2 Notification at the end of initial period 


Generally, the call is again connected to an operator at the end of 
the initial period. This operator is not likely to be the same person 
who handled the initial contact. The call arrives at the position with 
the appropriate keys and lamps lit to indicate that this is a notify 
seizure. The operator notifies the customer that the initial period has 
ended and requests that the customer signal (by flashing the switch- 
hook) when the call is completed. The operator releases the position 
and TspPs starts overtime timing. 


2.3 Quotation and collection of charges due for overtime 


If a call goes into overtime and reaches an elapsed time of 10 
overtime intervals (usually 10 minutes), an operator is reconnected to 
the customer’s line to request an intermediate deposit. This deposit is 
intended to limit coin overtime losses that result when a customer 
walks away at the completion of the call without paying the charges 
due. The operator counts the deposits and, when the request is 
satisfied, releases the position. Additional intermediate deposits are 
requested at appropriate intervals until the call terminates. Calls in 
overtime are not interrupted more frequently because of the operator 
work time penalty. 

When the call is concluded, as indicated to Tsps by the calling 
customer signaling (flashing the switchhook) or either customer hang- 
ing up, the call is brought to a position for overtime collection. If the 
calling customer’s phone is on hook, the operator rings the station by 
operating the ringback key. When the calling party is on the line, the 
operator requests the charges due and counts the coin deposits. When 
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the deposit request is satisfied, the operator thanks the customer, 
depresses a key which signals that coins are to be collected, and 
releases the position. If the calling customer does not answer the 
ringback or the operator is unable to obtain full payment for the call, 
a “walkaway” is recorded on a mark-sense ticket and the operator 
releases the position. 


lil. THE ACTS HARDWARE 


A new hardware subsystem is added to the TsPs for ACTS, called the 
Station Signaling and Announcement Subsystem (ssas). It is com- 
posed of a control unit containing a programmable controller called 
PROCON, an announcement store, and service circuits called Coin 
Detection and Announcement circuits (CDAs) (see Fig. 3). The control 
unit and announcement store are duplicated for reliability. One con- 
troller is active and the other is standby. The units are not run 
synchronously, but the temporary memory of each unit is updated on 
an ongoing basis. 

The ssas control unit contains the PROCON with a read-only program 
memory and a random access memory for temporary data storage. 
The ssas control unit provides an interface with the Stored Program 
Control (spc) unit,’ its mate controller, the announcement memory, 
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and the cDA service circuits. The SPC communicates every 25 ms with 
the ssas via software buffers as it does with other peripheral units. 

The PROCON handles the internal control, data manipulation, and 
data transfer required for processing the call through the successive 
steps from customer contact through deposit acknowledgment. Within 
each control unit, the PROCON provides a self-checking mechanism for 
immediate detection of faults. 

Prerecorded words and phases are digitally encoded and stored in 
the announcement store. The announcement store can be expanded in 
increments of eighty 512-ms speech segments. It is organized to be 
tolerant to single-bit faults and is diagnosed via the SPC. PROCON forms 
announcements by directing speech segments from the announcement 
store to the CDA in the appropriate sequence. 

The cDA circuits have appearances on the TSPS switching network 
and perform the functions of making announcements to customers and 
of detecting coin deposits. The cDA circuits also are used to monitor 
for coin deposits when an operator is handling the call. cpDAs are traffic- 
engineered with a typical TsPs requiring from 30 to 40 of these service 
circuits for AcTS. These service circuits convert the digital bit stream 
to an analog announcement. 


IV. COIN SERVICE WITH ACTS 


ACTS uses SSAS to automate the handling of (z) initial period coin 
collections, (ii) notifications of the end of the initial period, (viz) 
charge due coin collections, (iv) time and charge quotations, and (v) 
notifications on nonpaid calls. This section details the procedures used 
to automate these call seizures. 


4.1 Initial period coin collection 


With acts, a coin customer initiates a station-to-station call as in 
the past by dialing one* plus the called number. Since no local office 
trunk modifications are needed, the local office goes through normal 
routing of the call to Tsps. After TSPs receives the called and the calling 
numbers, it determines the rate and computes the initial period 
charges. However, instead of connecting an operator, TSPS makes 
network connections that bring the call to a cpa circuit and passes the 
initial period and charge information to the ssas. The call is not 
outpulsed forward until the ssas completes the initial contact with the 
customer. In the following sections, the procedures and announce- 
ments for the initial collection are described. 


* Some areas do not require the one to be dialed. 
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4.1.1 Initial deposit request 


The ssas constructs the following announcement: 


X dollar(s) 
“‘y X dollar(s) and Y cents / please.” (2-second pause) 
Y cents 


X dollar(s) 
“Please deposit } X dollar(s) and Y cents? for the first Z minute(s).” 
Y cents 


4.1.2 Initial coin prompt - 


In studies of customers making coin-paid toll calls, it was observed 
that many customers ask the operator to repeat the amount before 
they begin depositing. This even occurred on calls in which the amount 
was stated twice in the initial request. In view of this, if no deposit is 
detected within an allotted time after the initial announcement, the 
SSAS prompts the customer with, for example: 


“Please deposit 1 dollar and 50 cents.” 


Although a 5.5-second initial coin timing interval is used for the 
beginning of the call, all timing intervals are designed so that they can 
be changed in case significant differences in customer behavior are 
encountered as a result of growing customer familiarity with the 
service or as a result of demographic differences. 


4.1.3 Intercoin prompt 


Some customers begin depositing, but stop before the request is 
satisfied. For example, the customer may lose count of the coins 
deposited. To accommodate these customers, an intercoin prompt is 
given. If the time between coin deposits exceeds an allotted time and 
the deposit is not satisfied, the SSAs prompts the customer by announc- 
ing the additional deposit needed in a manner similar to the initial 
coin prompt. 


4.1.4 Acknowledgment of a correct deposit 


Data show that over 80 percent of the customers satisfy the deposit 
request within the allotted time intervals. When the customer deposits 
the correct amount, the ssas takes three actions. First, it informs the 
TSPs to outpulse the call. Second, while the call is being outpulsed, the 
SSAS acknowledges the deposit to the customer by 


“Thank you.” 


Third, when the announcement is completed, the ssas reports the 
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amount detected to Tsps. Following this report, the Tsps disconnects 
the CDA circuit and proceeds to time the call. 


4.1.5 Acknowledgment of an overdeposit 


Some customers lack the proper change and deposit too much 
money. With acts, an overdeposit is acknowledged and credit toward 
overtime charges is automatically obtained. This eliminates the need 
for a customer to indicate a credit is due. When the overdeposit is 
recognized, the ssAS informs TSPS to outpulse the call and to record 
the amount of the overdeposit. The ssas acknowledges the overdeposit 
with the following phase: 


“Thank you. You have W cents 
credit toward overtime.” 


If the customer does not use the overdeposit credit and wants a refund, 
the customer must reach an operator and request a refund. 

The ssAs does not time for overdeposits greater than breakage, but 
as long as the cDA circuit is attached, subsequent deposits are credited 
towards overtime. Breakage occurs when the denomination of the last 
coin brings the amount deposited over the amount due (i.e., $0.05, 
$0.10, $0.15, or $0.20). As soon as the amount deposited equals or 
exceeds the amount due, the ssas informs Tsps to outpulse. To time 
for additional overdeposits (i.e., prepayment of overtime), the Ssas 
would have to delay all calls. If the customer overdeposits inadvert- 
ently and wishes to redeposit the correct amount, the customer must 
hang up to have the coins returned. This can be done any time before 
the called party answers. 


4.1.6 Deposits during announcements 


The cDA circuits monitor coin deposits during deposit requests. If a 
coin is detected during a request, the request is truncated immediately. 
If this coin does not bring the amount deposited up to the amount 
due, intercoin timing begins. If the amount due is met, the appropriate 
acknowledgment is transmitted. This allows customers who know the 
charges for a call to deposit the required amount without listening to 
the entire deposit request. 


4.1.7 Operator assistance 


Coin customers may not properly respond to fully-automated service 
and may need operator assistance. For example, customers who lack 
the correct change may request that the charges be billed to a credit 
card, to a third party, or to the called party. To deal with such 
occurrences, an operator is needed. Thus, if the customer fails to 
deposit within the allotted time following a prompt, the call times out 
and receives operator assistance. In addition, if a customer flashes the 


1216 THE BELL SYSTEM TECHNICAL JOURNAL, JULY-AUGUST 1979 


switchhook during the coin deposit announcements, the call is also 
brought to an operator. 

When the operator is attached, a new pattern of keys and lamps as 
well as a new numeric display (see Fig. 2) are lit on the operator 
console. This informs the operator of an ACTS call and provides the 
operator with the additional information concerning the amount still 
to be deposited. The CDA circuit remains connected between the 
customer and the operator. The circuit continues to monitor coin 
deposits but makes no announcements. The operator assists the cus- 
tomer in making a full deposit. 

When the cDA circuit detects the full deposit, the ssas reports 
“deposit satisfied” to the Tsps. The Tsps updates the operator’s nu- 
meric display and outpulses the call. If the coin deposit tones are not 
being accepted by the cDA circuit and the operator suspects an equip- 
ment malfunction, the operator can override the ssas and allow the 
call to progress. 


4.2 Notification at the end of the initial period 


The ssAs can provide the notification of the end of the initial period 
on all coin-paid calls whether the initial contact was handled by the 
SSAS or by an operator. When the initial period timing ends, the call is 
connected to a CDA circuit instead of an operator. TSPS informs the 
SsSAS of the length of the initial period and the cpa circuit being used. 
The ssas then announces to the customer: 


“7, minute(s) has ended. Please 
signal when through” 


where Z ranges between 1 and 6. 

When the announcement is complete, the ssas informs the TsPs that 
the CDA circuit is idle. The Tsps disconnects the CDA circuit and starts 
overtime timing. 


4.3 Charge due seizures 


The acts procedures for fully automating overtime charge due 
seizures on coin-paid calls are presented in this section. The same 
sequence of deposit requests, coin deposit timing, prompting, and 
acknowledging described for the initial period deposit request are used 
for the overtime deposit request. However, the announcement wording 
is appropriately changed to indicate that money is due for the preced- 
ing connection time. 


4.3.1 Charge due deposit request 


In the same way as before acts, if a call lasts a certain number of 
overtime intervals, an intermediate deposit is requested from the 
customer. With Generic 8, the number of overtime intervals can be 
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varied in accordance with the amount of overtime charges (previously 
it was fixed at 10). Additional intermediate deposits are requested 
until the call terminates. The ssas automates the collection at both 
intermediate and end-of-call overtime charge due seizures on ACTS- 
handled calls. The collection sequences for end-of-call deposits and 
intermediate deposits are essentially the same.* Furthermore, these 
collection sequences are very similar to those used for the initial 
contact on station (1+) calls. 

Without interrupting the conversation path, TSPs connects an idle 
CDA circuit to the call. Tsps informs the SsAs of the amount due, the 
number of minutes talked, the CDA circuit being used, and the fact 
that it is a charge-due seizure. The SSAS generates an announcement 
similar to that used for initial coin deposit requests. 

If the customer overdeposited during the previous collection se- 
quence, the credit is automatically given. The overdeposit is subtracted 
from the calculated charges due. If no money is due, no actions are 
taken. If money is due, the TSPS connects an idle CDA circuit to the 
call. TsPs informs the sSsAs of the amount due, the amount of credit, 
the number of chargeable minutes, the cDA circuit being used, and that 
it is a charge-due seizure with credit. 

To assure the customer that credit is being given, an announcement 
is used, such as 


“2 dollars and 10 cents please.” (2-second pause) “You have 20 
cents credit. Please deposit 2 dollars and 10 cents more for the 
past 10 minutes.” 


After the charge-due deposit request is made, the deposit timing 
and, if needed, the prompting announcements described for the initial 
contact are used. If the deposit request is satisfied, the “Thank You” 
acknowledgment is given. When the ssas informs Tsps that the ac- 
knowledgment is completed, the CDA circuit is disconnected from the 
call. 

As with initial contact, operator assistance is given if no coin is 
deposited within a time interval, presently set at 5.5 seconds, or if the 
customer flashes during the deposit sequence. An operator is also 
connected if the customer goes on-hook during the announcement 
sequence. 


4.3.2 Walkaways 


If the calling customer goes on-hook at the end of a coin-paid call 
and charges are due, TSPS automatically generates a ringback signal to 


* With intermediate deposits, the called party is off-hook. A special coin detection 
arrangement is used to monitor the calling and called stations. 
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cause the calling phone to ring. If the calling party answers, an ACTS 
overtime charge due announcement is made. The start of the an- 
nouncement is delayed 2 seconds from the time the customer goes off- 
hook. This allows time for the customer to get the handset to the ear. 

However, if the calling party does not answer, TSPS assumes a 
walkaway. Since the customer did not respond to an automatic ring- 
back, the customer probably will not respond to an operator ringback. 
Hence, an operator is not connected. Instead, a traffic counter is 
pegged and a walkaway record is made on the Automatic Message 
Accounting (AMA) tape. These walkaway records can be processed 
later to determine patterns so that action can be taken to reduce 
fraudulent use of coin phones. 


4.4 Time and charge quotations 


When a customer requests a time and charge (T&C) quotation on a 
call, the operator instructs the customer to flash and remain off-hook 
at the end of the call. If the customer follows the operator’s instructions 
and the called party goes on-hook for two or more seconds, the forward 
connection is released and the call is connected to an idle CDA circuit. 
TSPs informs the ssAs of the charges, the length of conversation, the 
CDA being used, and that it is a time and charge quotation. The ssas 
generates an announcement, such as 


“The charges are 3 dollars and 94 cents plus tax for 12 minutes.” 


If the calling customer remains off-hook, the quote is repeated 3 
seconds later. The ssas informs Tsps when the second quote is com- 
pleted, and the call is terminated. If the calling customer goes on-hook 
during this sequence, TSPS informs the SSAS to suspend the announce- 
ment sequence, and the CDA circuit is idled. 

The fully automated quotation is given only to calling customers 
who remain off-hook at the end of the call. If the calling customer goes 
on-hook at the end of the call, TsPs connects an operator to contact 
the calling customer and give the T&C quotation. An operator is 
required because a system ringback may not be answered by the 
calling customer. For example, a ringback could be answered by a PBX 
attendant who knows nothing about the call. 

When the ssas gives the T&C quotation, the AMA record specifies 
that an SSAS quotation was given and the charges the customer was 
quoted. 


4.5 Customer requested notification 


On a call that is not coin-paid, a customer can ask to be notified at 
the end of 1 to 10 minutes. During the initial contact, the operator 
enters the customer’s request into TSPS memory. If such an entry is 


ACTS: OVERALL DESCRIPTION 1219 


made, TSPS connects the idle CDA circuit to the call at the appropriate 
time. TsPS informs the ssas of the CDA circuit being used, the number 
of elapsed minutes, and that it is a notification seizure. The SsAs 
generates the prescribed tone and announces, for example, 


“5 minutes has ended.” 


When the ssas informs the Tsps that the announcement is finished, 
TSPsS disconnects the CDA circuit and continues to time the call. 


V. ADDITIONAL TSPS FEATURES ON GENERIC 8 


In parallel with the acts development, other service and mainte- 
nance features were developed. Those features are released with ACTS 
in a software package known as a generic. Since the generic containing 
ACTS is the eighth for Tsps No. 1, it is called Generic 8. This section 
briefly describes some of the additional features in Generic 8. 


5.1 Expanded dialing to Mexico 


This feature expands customer dialing capability on calls to Mexico. 
The Generic 8 dialing plan for Mexico is eight digits, except that the 
Northwest border area has a 903 area code followed by seven digits. 
Presently, calls to the 903 and 905 (Mexico City) area codes are 
customer dialable. (In the case of Mexico City, the digit “5” is both the 
third digit of the area code and the first of the eight digits in the dialing 
plan for Mexico.) Other calls to Mexico are only dialable by an 
operator, and many areas can only be reached by an inward operator. 

The expanded Generic 8 capability allows customers to dial directly, 
using the international format, calls that currently are only dialable by 
an operator. Specifically, a customer dials 011 or 01 plus a country 
code of 52 plus the 8-digit Mexican number. TsPs software recognized 
the 52 country code and bypasses the 2-stage outpulsing normally done 
on international calls. Tsps then outpulses 180 plus the 8-digit number 
for routine handling (6-digit translation) in the domestic toll network. 
A toll office with trunks to Mexico eventually is reached and outpulses 
the 8-digit number. In Generic 8, TsPs also continues to handle calls 
dialed using the 903 and 905 formats. 

Besides expanding direct dialing, this feature also simplifies inward 
calls to Mexico. The Tsps operator keys 52x-121, where x = 5 for 
Mexico City, 8 for Monterrey, 1 for Chihuahua, or 6 for Hermosillo. 
TSPS uses the “x” digit to index into a translation table. This table 
contains the codes to be outpulsed to reach the appropriate Terminat- 
ing Toll Center. 

This feature improves service by allowing the customer to dial calls 
directly. It also is expected to yield significant economic savings by 
automating a class of traffic that is experiencing substantial annual 
growth. 
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5.2 Transfer CAMA queuing improvement 


In some cases, TSPS operators provide Operator Number Identifica- 
tion (ONI) to a CAMA office which will record the billing information. 
For instance, many TspPss handle transfer CAMA traffic at night, when 
CAMA boards are closed and traffic is normally light. If traffic fluctua- 
tions produce a relatively heavy load, incoming calls can experience 
delays before reaching an operator position. Generic 8 has an improved 
strategy, called delay ratio control queuing, for handling traffic in TSPs 
offices which perform a transfer CAMA function. 

This new queuing strategy tends to maintain a preselected balance 
between the delays experienced by transfer CAMA and other TSPS 
customers. A separate queue is established for transfer CAMA calls 
waiting for a position. Other TSPS customers queue as they do now. 
The serving rate for transfer CAMA versus other TSPS customers is 
dynamically modulated by the ratio of the respective queue lengths. 
This approach has been verified by analytical simulation and field 
studies to provide better service to CAMA customers while maintaining 
good service to other TSPS customers. 


5.3 Dynamic queuing strategy 


The dynamic queuing feature provides measurements and controls 
of the delays experienced by calls which require an operator position. 
The delay measurements are used to determine when to light a “calls 
waiting” lamp indicating to the operators that a moderate number of 
customers are awaiting assistance. Operators can then expedite call 
handling. If the delays increase further, the dynamic queuing mea- 
surements trigger the application of delay announcements.* These 
announcements turn away some of the new calls that would otherwise 
enter the queues. 

Previously, the number of TSPS positions staffed was used to index 
into tables giving critical queue lengths for activating delay announce- 
ments and the call waiting lamp. These tables were originally con- 
structed on the assumption of a fixed (60-second) Average Work Time 
(AwWT) per call. Tables based on fixed AwT are insensitive to variations 
in service rate. 

The dynamic queuing feature measures the actual delay encountered 
by incoming calls. Call abandonments are also directly taken into 
account, since they affect the measured delay. This accurate delay 
estimate improves service to TSPS customers. The dynamic queuing 
feature interacts constructively with the transfer CAMA queuing fea- 
ture, since separate data can be obtained on the delays seen in the 
transfer CAMA queue. An integrated approach to lighting the call 


* Position disconnect is supplied on transfer CAMA trunks so that reorder can be given 
at the toll office. The delay announcement is given to other tsps traffic. 
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waiting lamp and turning on the delay announcement (or supplying 
position disconnect) is based on accurate assessments of all the queuing 
delays in the system. 


5.4 Redistributing (rehome) TSPS trunks 


The ability to redistribute (rehome) TsPs trunks to a different toll or 
local offices allows an operating company to react to changing traffic 
trends. This ability allows TSPS capacity to be efficiently used in 
adapting to the evolving traffic patterns. Rehoming can be used to 
relieve congestion at a toll office or when an existing office is being 

-replaced by a more modern electronic office. As an example, perhaps 
a No. 4A Crossbar office is being replaced by a No. 4 ESS. 

Office data parameters for the trunks can be changed en masse. The 
software limitation of a single office parameter per trunk group is 
deleted for rehome. The software accommodates a difference (for 
instance, wink versus delay dial signaling) between the offices. 


5.5 Improved coin station tests capabilities 


TSPs Generic 8 provides a new coin station test capability. With this 
capability, a craftsperson can make end-to-end, coin signaling tests 
between coin stations and Tsps. This new procedure directs the crafts- 
person at the coin station through a series of tests. The SSAS is utilized 
to provide appropriate feedback to the craftsperson concerning the 
denomination of the detected coins. Marginal/stress testing is an 
integral part of the test. With the test information, the craftsperson is 
able to determine whether the station is functioning correctly and, if 
not, what functional area of the station is defective. In addition, certain 
types of coin-deposit signaling errors detected by the SSAs are recorded 
with other call billing details. This failure information can be sum- 
marized by a telephone company using the new Coin Operational and 
Information Network (COIN) package.* This information can be used 
to direct the craftsperson to potentially defective coin stations. To- 
gether, the per-call failure information and the quick, simple, and 
flexible coin station procedures provide the telephone companies with 
improved detection and resolution of coin system problems. 


Vi. ACTS DEPLOYMENT AND ECONOMICS 


Today, over 75 percent of the coin stations and 80 percent of the 
average business-day, coin-paid calls in the Bell System are handled 
on TSPs, and this coverage is increasing each year. The incorporation 
of ACTS into TSPS eliminates or reduces operator handling of most of 


* coin is an off-line computer package which performs collection, scheduling, and 
revenue analysis functions for public telephones. 
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these coin-paid calls, thereby achieving significant operating expense 
savings for the Bell System. 

To achieve these savings, the previously described hardware and 
software are added to Tsps. In preparation for the introduction of ACTS 
in the Bell System, new coin stations and coin chassis produced by 
Western Electric since 1975 have been (and will continue to be) 
equipped for ACTS coin detection. 

On November 26, 1977, the first new TSPS equipped with the AcTs 
feature was introduced into service in Phoenix, Arizona. In March, 
1978, an existing TSPS was first retrofitted with the Generic 8 features 
in Oakbrook, Illinois. 

ACTS was made available on a standard basis to the Bell System 
operating companies in the middle of 1978. 
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A new subsystem, Station Signaling and Announcement Subsystem 
(SSAS), was added to TSPS to provide automated coin toll service. 
Presented here are descriptions of how this new subsystem generates 
announcements from digitally stored speech samples, how it responds 
to coin deposit signals from coin stations, how the announcement 
circuits and coin tone detection circuits are automatically tested, and 
how the subsystem is physically packaged. 


|. INTRODUCTION 


The new functions needed in Tsps for Automated Coin Toll Service 
are provided by the newly designed Station Signaling and Announce- 
ment Subsystem (SSAS). SSAS delivers voice announcements to cus- 
tomers at coin stations and responds to the coin deposit signals 
generated at the coin stations. 

SSAS can be described from two perspectives, that of a coin toll 
customer and that of the Tsps processor. From the coin toll customer’s 
viewpoint, it should sound and react the same as or better than the 
human operators the customer is accustomed to. From the standpoint 
of the TsPs processor, it operates as an “intelligent peripheral,” using 
the existing instruction and data buses. In response to TSPS instruc- 
tions, it constructs announcements to request and acknowledge coin 
deposits. It keeps track of each customer’s coin deposits and then 
reports the amount of the completed deposit to the processor, which 
then sets up the call. If the customer does not deposit enough coins, 
ssas delivers requests for the balance, or finally sends a time-out 
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report to the processor so an operator can be brought in to assist the 
customer. To provide reliable service, the ssAs control circuits are 
duplicated, with one control circuit active and the other standby. They 
contain self-checking features so faults can be detected promptly and 
reported to the TsPs processor, enabling a smooth switchover from the 
active to the standby ssAs controller. 

The interface of SSAS with customers is through a number (up to 
239 per system) of Coin Detection and Announcement circuits (CDAS). 
Each cpa provides service to one customer at a time. Each CDA 
contains a coin tone receiver that recognizes the nickel, dime, and 
quarter deposit signals from dual-frequency, single-slot, coin stations. 
Each cDA also contains a digital-to-analog decoder that converts bits 
at 31,250 b/s into natural-sounding voice announcements. To provide 
for connecting an operator if the customer has difficulty and to reduce 
the possibility that operator or automated announcement speech will 
interfere with correct coin recognition, each cDA also includes a 4-wire, 
voice-frequency network with an extra port for the operator. Each 
network contains 4-wire terminating sets and amplifiers to isolate the 
coin-tone receiver and digital-to-analog decoder from one another. In 
addition to the customer-serving CDAs, each SSAS contains one unique 
CDA circuit that functions as a built-in test set. 

Figure 1 shows the essential parts of a connection from a customer 
to an SSAS CDA. 

Before the advent of SSAS, a coin call needing TSPS operator service 
would be connected through a Tsps trunk and the TsPs network to an 
operator position or to a service circuit for ringing or busy tone. With 
SSAS, a call identified as eligible for automated coin detection handling 
is immediately connected to a cDA. If it later develops that an operator 
is needed, one can be connected to speak to the customer or to listen 
to the automated announcements and coin signals. 

Figure 2 shows the principal parts of sSAs along with the input and 
output data bus connections to the TSPS processor. 

The coin-tone receivers in the cDAs deliver detected coin data to 
digital registers, also in the cpAs. These registers are scanned period- 
ically, and the data are ultimately relayed back to the TSPs processor. 
The digital-to-analog decoders that deliver the announcements were 
adapted from an earlier Bell Laboratories design, Subscriber Loop 
Carrier 40 (SLC™-40). They are preceded by serial buffers that are 
loaded sequentially, with bursts of 40 bits transmitted at a 1-mHz rate. 
The bits are decoded at a steady rate of 31,250 b/s. 

As mentioned earlier, as many as 239 CDAs can be associated with 
one SSAS. Since the holding time needed to request and collect coin 
deposits for a typical call is relatively short, 239 is expected to be 
enough cDAs to handle the coin toll traffic in large metropolitan TSPs 
offices. The cDAs are operated by a controller frame and an associated 
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Fig. 1—Connection of ssas CDA into TSPS. 


semiconductor announcement store. For backup in case of failure, 
there is an identical controller frame/announcement store pair. The 
announcement store, except for minor modifications to make it acces- 
sible either from the ssas controller or the TSPs processor, is the same 
design as the TSPS processor main store frames. It may contain up to 
six memory modules, each containing 32K 47-bit words. Forty bits of 
each word are data; seven are used for error detection and correction. 

The controller frame contains a programmable controller (PROCON) 
and wired logic which, in response to instructions from the TSPs 
processor, retrieves samples of digitized speech from the announce- 
ment store and distributes them in a multiplexed scheme, with a fixed 
sequence, 40 bits at a time, to the cDAs. The announcement distribution 
sequence has 256 time slots, of which 16 are used for test instructions 
and 240 are used to deliver bits to the 239 cDAs and the one test 
channel. The distribution sequence is repeated every 1.28 ms, so that 
each CDA, using bits out of its serial buffer at a rate of 31,250 b/s, for 
announcement generation, is supplied with precisely enough data to 
produce uninterrupted announcements consisting of 512-ms segments 
joined together. 
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Fig. 2—ssas block diagram. 


If an office were equipped with the full complement of 239 cDAs, it 
could deliver announcements to 239 customers simultaneously. When 
there are not 239 cDAs installed, or when not all installed cDAs are in 
use, a bit pattern representing silence is placed in each inactive time 
slot. 

At the same time that the PROCON in the ssAS controller is distrib- 
uting 40-bit digitized speech segments to the cDAs, it is sequentially 
scanning, over separate data paths, registers connected to the outputs 
of the coin tone receivers in the CDAs to gather data on coin deposits. 
The coin deposit data, including the time when the deposits occurred, 
is stored by the PROCON in “scratch pad” memory. The deposit and 
time data are used to determine future actions, i.e., additional an- 
nouncements or reports to the TSPS processor when the deposits are 
sufficient. 

Both the active and standby controllers have access (one at a time) 
to all cpAs. The two controllers do not operate synchronously with 
matching for error detection. Each, however, contains a close tolerance 
crystal-controlled clock, so any time difference between them would 
be only a few microseconds, a difference not noticeable to customers 
in the event of a switchover. The maintenance and initial loading of 
the announcement stores takes place over the store maintenance paths 
shown in Fig. 2. These paths, in fact, are extensions of the existing 
TSPS processor store buses. 

The updating link shown between the two ssas controllers is a 
parallel, 17-bit (16 plus parity), 1-mHz link interconnecting the PRo- 
CONs in the two controller frames. This link provides two very powerful 
features. First, if one announcement store is powered down for main- 
tenance, reloading over the store bus would require human action to 
set up a tape drive and many minutes of loading time. With the 
updating link, however, the PROCON in the active controller can, 
interleaved with normal handling of announcements and coin data, 
transmit in a few seconds the entire contents of the active announce- 
ment store to the just-restored inactive announcement store. 

Second, while the active controller is dealing with the ever-changing 
coin collection data stored in its “scratch pad” memory, the same data 
are being continuously relayed through the updating link to the 
memory of the standby controller. This makes it possible to perform 
a planned or unplanned switchover to the standby controller, usually 
without interrupting announcements or losing track of the coins that 
as many as 239 customers may be in the process of depositing. 


ll. DETAILED HARDWARE IMPLEMENTATION 


The development of SSAS includes several areas that are felt to be of 
some general interest and will be discussed further here. These are: 
1. Storage, retrieval, and decoding of announcements. 
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2. Coin deposit signaling and detection. 
3. Automated testing of coin detection and announcement circuits. 
4. Physical design. 


2.1 Announcement storage and processing 


The continuing orders-of-magnitude decrease in the cost of digital 
memories made it clear that the storage of announcements for SSAS 
should be digital rather than analog. A major decision for SSAS was 
whether to use writable store (RAM) or read-only memory (ROM) to 
store the announcement vocabulary. For some recently developed or 
proposed “talking” systems, ROM is clearly the better choice. For 
personal calculators for the blind, for example, the vocabulary is well 
defined to include just the digits zero through nine and the names of 
the arithmetic operations. Reloading a volatile memory in a portable 
calculator would be clearly impractical. Also, ROMs can be packaged 
more densely. For ssas, however, although the vocabulary for coin 
traffic might appear to be constant, it is subject to change when call- 
handling practices change. There may have to be vocabulary differ- 
ences among operating companies because of differences in their 
practices concerning overtime collection. More important, when new 
features are added to SSAS, a significant amount of new vocabulary 
will have to be added. If the ssAs vocabulary were stored in read-only- 
memory, the logistics and cost of managing spares, repairs, and addi- 
tions appear to be objectionable. With a writable memory of the type 
already in use in TSPS, no special handling of memory units will be 
needed. New vocabulary can be distributed to operating companies as 
needed on reels of magnetic tape, using administration procedures 
already established for distribution of Tsps software updates. Although 
data in a writable store are subject to loss in the event of a power 
failure, the back-up power arrangements in Bell System central offices 
make a shutdown of both announcement memories unlikely; if it does 
occur, their contents can be restored from a tape stored in the office. 

The SSAS announcement vocabulary presently includes 80 512-ms 
speech segments and the equivalent of 15 more speech segments 
containing test tones and timing data for automatic self-testing. Each 
512-ms segment requires 16,000 bits, stored in the 40-bit data portion 
of the words at 400 consecutive addresses in the announcement store. 

The semiconductor program/data store recently developed for use 
in TSPS was selected for use with some modification as the SSAs 
announcement store. Figure 3 is a photograph of this store. This store 
frame can be equipped with up to six modules, each holding 32,000 47- 
bit digital words. The 95 presently used vocabulary segments require 
38,000 digital words, so the frame presently used in SSAS is equipped 
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Fig. 3—Announcement store frame. 
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with only two memory modules. A store frame fully equipped with six 
modules would accommodate 480 512-ms segments. Since 95 are now 
in use for ACTS, as many as 385 more could be made available for new 
features. As mentioned earlier, the announcement store frame differs 
from a TSPS main store frame only by the addition of a selector to 
provide access either from the ssas controller or the TsPs store bus. 

The vocabulary of 80 words needed for the SSAS announcements was 
recorded by a professional announcer. The words were then digitally 
encoded using adaptive delta modulation with a bit rate of 31,250 per 
second. Next they were edited into 80 512-ms segments, each contain- 
ing 16,000 bits. The editing was a subjective listening process, with 
attention paid to level, pitch, and the silent periods adjacent to each 
piece of speech, to assure the most natural possible sound when the 
pieces are rejoined in various combinations to form sentences. Many 
words are complete in a single 512-ms segment; the numbers over 20 
and some common parts of announcements (e.g., “Please deposit’) 
require two segments to complete. The words that are used both in 
the middle and at the end of sentences are included twice with two 
different inflections. The 15 equivalent segments containing test tones 
were recorded using laboratory signal generators. 

The adaptive delta modulation (ADM) encoder used for the an- 
nouncement recording and the decoders used in the CDAs were devel- 
oped earlier at Bell Laboratories for use in the Subscriber Loop Carrier 
System (SLC-40) and are described in detail in Ref. 1. Briefly, ADM 
is a process for encoding a signal into a train of ones and zeros which 
are then decoded by the simple process of using each one to increment 
the charge on a capacitor in the positive direction and using each zero 
to decrement the charge by the same amount. Since the bit rate is 
several times higher than the highest voice frequency, the “‘stairsteps” 
in the wave can be easily filtered out. The delta modulation encoding 
and decoding process is made “adaptive” by using the last few bits in 
the pulse train to control the magnitude of the current generator that 
is used to increment the charge on the decoding capacitor. The rates 
of increase and decrease of the adaptive current generator are con- 
trolled by R-C networks tailored to the average parameters of speech 
syllables. 

Adaptive delta modulation produces thoroughly adequate announce- 
ment quality using 31,250 bits per second, about half the bit rate that 
would be needed by 7- or 8-bit pulse code modulation (PCM) using an 
8-kHz sampling rate. 

The announcement decoder for each of the SSAS CDAs is on a single 
6-by-8-inch circuit pack. Each pack includes the decoder circuit from 
the SLC-40 design (adapted for slightly different power supply volt- 
ages), a “silence” generator, and a serial input buffer. The silence 
generator is a flip-flop controlled by a clock to produce alternating 
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ones and zeros. It is intended to be brought into operation in midword 
to silence an announcement quickly when a customer starts to deposit 
coins. This feature allows a substantial speedup in service for cus- 
tomers who already know the charges for calls they are making. The 
serial input buffer is a self-shifting, first-in/first-out (FIFO) shift register 
device, available commercially from several manufacturers. It is loaded 
at a 1.0-mHz rate each time the 40-bit data bursts arrive. It is unloaded 
continuously into the decoder circuit by the 31,250-Hz clock distributed 
to all the cDAs. 

The sequential distribution of 40-bit announcement segments to all 
the cpDAs is controlled by the PROCON and by wired logic that auto- 
matically steps through the 400 store addresses for each speech seg- 
ment and distributes the data to the 239 cDAs and one test circuit. The 
retrieval of the words from the 400 consecutive announcement store 
addresses is controlled from a pair of 256-word recirculating shift 
registers. These shift registers are used in an alternating fashion. One 
is loaded by the PROCON with the 256 initial addresses of the announce- 
ment segments needed for the next upcoming 512-ms period. One 
particular address is used to represent silence for inactive or une- 
quipped cpaAs. The second shift register, which was previously loaded 
with the initial addresses for all the announcements (or 512-ms silence 
segments) in progress, is recirculated 400 times, and each time a one 
is added to all the addresses. Thus the set of 256 starting addresses is 
altered at each recirculation to step through the 399 addresses that 
follow each initial address. These addresses are used to retrieve the 
announcement data words, which are then distributed in sequence to 
the cpas for decoding. After the 400 recirculations, the roles of the two 
recirculating shift registers are reversed. The recirculation and incre- 
menting begins with the new set of starting addresses, and the just- 
exhausted shift register is loaded with the still newer set of starting 
addresses for the next 512 ms of announcements. Each 512-ms interval, 
when a new set of announcement addresses is loaded, is referred to as 
a “base period.” 


2.2 Coin deposit signaling and detection 


Coin deposits were reported to an operator for many years through 
a largely mechanical system. In the widely used 3-slot coin station, the 
coins rolled and bounced against gongs to produce “bing” for a nickel, 
“bing-bing” for a dime, and “bong” for a quarter. To provide added 
flexibility for changes in the initial deposit on local calls and to provide 
substantially more protection against counterfeit coins and slugs, a 
new single-slot coin station was introduced in 1966. In this coin station, 
the coins, after passing through a mechanism that tests them for 
dimensions, mass, and conductivity, trigger an electromechanical de- 
vice called a totalizer. After each coin passes, the totalizer resets itself, 


ACTS SSAS HARDWARE 1233 


and in so doing, momentarily switches on a pulsed-electronic oscillator 
that produces one “beep” for a nickel, two for a dime, and five for a 
quarter. In principle, single-frequency “beeps” from such a coin station 
could be recognized by a tuned electronic detector and counter. How- 
ever, Bell System experience with multifrequency and TOUCH- 
TONE® signaling indicated that adequate protection against errors 
caused by speech or noise could be provided only by using dual- 
frequency “beeps” to represent coin deposits. Accordingly, a low-cost 
dual-frequency oscillator assembly was designed and introduced into 
the manufacture and refurbishment of coin stations starting in 1975. 
This was done deliberately well in advance of the service cutover of 
SSAS (late 1977) so that a minimum of coin station modification visits 
would be needed when Automated Coin Toll Service is introduced to 
an area. 


2.2.1 Coin tone receiver operating environment 


Coin tone signaling may take place in the presence of ambient 
speech and noise. Speech interference, for example, may be due to a 
synthesized announcement in progress, customer speech, an operator 
talking, or background noise at the coin station at the same time that 
coins are being deposited. The ssAs coin tone receiver is required to 
respond correctly to these coin tone signals in the presence of such 
speech or noise interference. The human ear (and mind) usually has 
no problem identifying tone signals in the presence of speech and can 
easily differentiate tone signals from speech. Electronic detection of 
tone signals, if it involved only receivers tuned to the specific frequen- 
cies, would be vulnerable to errors from speech signals since vowel 
sounds in speech frequently contain frequency components in the 
recognition band of the coin tone receiver. 

The speed of operation of the electromechanical totalizers in the 
coin stations is affected by temperature, by the dc current available 
from the loop to the central office, and by wear of the totalizer parts. 
Consequently, the coin tone receiver must accept a coin deposit signal 
whose timing varies over a considerable range. 


2.2.2 Coin tone receiver overall design philosophy 


The basic design requirements can be summarized as follows. The 
coin tone receiver should: 
(i) Recognize coin tones from widely ranging coin stations. 
(it) Identify a coin station whose performance is outside of require- 
ments. 
(iii) Operate in the presence of speech. 
‘(tv) Reject coin simulations. 
The first two requirements are met by accurate timing of the 
received signal to identify both valid coin deposit sequences and those 
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from coin stations with defective timing mechanisms. The third and 
fourth requirements, operating in the presence of speech while reject- 
ing coin simulations, are major considerations and have a significant 
impact on the receiver’s design. As was mentioned earlier, speech may 
frequently contain sufficiently sustained tone components that simu- 
late coin deposits. By using dual-frequency coin signaling for ACTs, 
where both tones have to be present simultaneously for a signal to be 
valid, the coin simulation rate is reduced by a considerable degree. A 
simple detector that looks only for the presence of the two required 
frequencies, however, still does not provide adequate simulation im- 
munity. Further receiver protection against coin simulations by speech 
is obtained by looking at other energy (called guard energy) besides 
the signal frequencies. If the guard energy is sufficient, the “signal” is 
assumed to be speech, and tone detection is blocked even though 
signaling energy may also be present. However, speech from the 
operator, announcement, or the calling station may be present while 
coins are being deposited. Thus receivers designed to give good coin 
simulation protection may be blocked or “talked down” when speech 
or noise is superimposed on tone signals. This can be seen in Fig. 4, 
where ambient speech interferes with and partially blocks tone detec- 
tion and at the same time causes false detection (coin simulation) 
during the silent interval between bursts. Since the cure for one 
problem makes the other worse, a compromise but exacting choice 
must be made in establishing receiver operating parameters. 

To reduce the effect of “talkdown” and coin simulation due to the 
operator and/or announcement, a four-wire terminating set is used to 
isolate the receiver from speech signals directed toward the originating 
station. However, because of nonideal return losses associated with 
trunks, loops, and various terminations, some portion of this speech 
energy is reflected back to the coin tone receiver. The returned signal 
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Fig. 4—Coin signal in the presence of speech. 
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is usually at a considerably lower level so that the probability of 
interference with signal reception is substantially reduced. 

The interfering effect of the announcement is reduced even further 
by truncating it at the earliest indication of a received coin tone signal. 
The receiver sends to the ADM circuit pack in the CDA a command to 
truncate the announcement even before the minimum duration legiti- 
mate coin burst is timed. Hence, if a false detection were due to 
signaling frequency components within the announcement itself, the 
signal would disappear before a coin simulation could be produced. If 
the detection were legitimate, truncation would prevent any further 
talkdown by the announcement. 


2.2.3 Coin tone receiver subdivision 


Notwithstanding the coin simulation and talkdown protection pro- 
vided by the four-wire terminating sets and announcement truncation, 
the receiver itself must have additional safeguards to distinguish 
between speech and coin tones, yet recognize tones in the presence of 
speech. This is accomplished in a two-phase processing approach: tone 
recognition and tone validation. The front-end analog tone recognition 
portion of the receiver “detects” the signal while providing the initial 
balance between coin simulation protection and “talkdown’’ protec- 
tion; the digital tone validation timing portion then applies different 
validity standards to various portions of the “detected” signal to 
determine the coin denomination. 

The analog portion (Fig. 5) is similar in principle to existing receiver 
designs for TOUCH-TONE signaling. (TOUCH-TONE signaling 
and receiver design considerations are described in Ref. 2.) It consists 
of filters, limiters, and detectors which produce a logic 1 output to the 
timing circuitry when both signal frequencies are simultaneously de- 
tected. As was mentioned earlier, tone detection is blocked when 
sufficient “guard” energy is present. The input bandpass filter (BPF) 
controls the total frequency range of signals entering the receiver. If 
this filter is broad, a considerable spectrum of the speech energy 
entering the receiver will be applied to the limiters. If the speech 
contains components at the signaling frequencies, it is likely that these 
components will be dominated by the other speech components, which 
will “capture” the limiters. Thus the signaling components passing 
through the bandpass filters, which follow, will not be of sufficient 
amplitude to operate the detectors. This method of preventing coin 
simulation is known as “limiter-guard action” and is the technique 
employed in TOUCH-TONE signaling to reduce the incidence of digit 
simulations. Therefore, a broad input BPF provides good coin simula- 
tion protection. If, however, legitimate coin signals are being transmit- 
ted while speech is present, they may also be blocked by speech. 
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Hence, “talkdown” protection will be poor. If the input BPF is narrowed 
(the input BPF must be at least wide enough to pass the two signaling 
frequencies), less speech energy can get through and, while “talkdown” 
is improved, less protection is provided against coin simulation. Based 
on laboratory and field tests, a filter was selected to optimize the 
tradeoff between the detector’s coin simulation and “talkdown” pro- 
tection. 

The logic signal indicating dual-tone detection is applied to the 
receiver’s tone validation timing circuitry which performs the following 
functions: 

(t) Processes the detected signal (refer to Fig. 4 for a sample 
detected signal) to form “discrete” burst and silent interval 
logic signals in accordance with the timing algorithm by filling 
in some gaps while ignoring some burst portions. 

(tt) Totalizes the number of “discrete” bursts received. 

(tii) Categorizes each “discrete” burst or silent interval after it is 
formed and makes a preliminary determination of the coin 
denomination at that time. 

(tv) Checks for consistency with previous burst and silent intervals 

to narrow the denomination possibility for that coin and also 
check for coin station timing malfunctions. 
Outputs the coin denomination or timing error signal when 
certain conditions are satisfied regarding the number of bursts 
received, the apparent coin category, and the amount of silence 
since the end of the last burst. 


_— 


(v 


2.2.4 Receiver outputs 


As the receiver performs signal timing in accordance with the timing 
flow diagram in Fig. 6a, certain output conditions may be satisfied and 
an output representing one of the coin denominations or a timing error 
(representing an out-of-tolerance coin station) will be delivered to a 
CDA data register. Before any coin or timing error outputs can be sent, 
however, the receiver must first deliver a Signal Processing (SP) signal. 
The sp signal is sent when the timing of the first burst of a suspected 
coin deposit reaches a certain minimum value. It remains active until 
a coin identification or timing error output signal is transmitted or the 
suspected coin deposit is deemed to be a coin simulation. At that time 
processing for the coin is assumed to be completed. The sp signal is 
used in the announcement decoder to truncate the announcement (see 
Section 2.2.2) by switching in the silence generator. The receiver also 
sends a psT (data strobe) signal along with the outputs, which gates 
the coin denomination or timing error indication into a data register in 
the CDA. 
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Fig. 6—Timing algorithm. (a) Algorithm flow. (b) Sample detected signal sequence. 


2.2.5 Circuit implementation 


The tone detection portion of the receiver (see Fig. 5) is based on 
existing receiver designs for TOUCH-TONE signaling. The input 
bandpass filter, which is critical to the detector’s response to speech 
and also to its performance when tones are being received in the 
presence of speech, was discussed in detail in Section 2.2.3. 
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Following the bandpass filter are two band-elimination filters (BEFs) 
in parallel. The width of these filters is tailored to the tolerances of the 
coin station oscillators. The first filter rejects the higher of the two 
signaling frequencies, and the second filter rejects the lower. Thus the 
output of the high BEF will contain the lower of the two signaling 
frequencies, and the output of the low BEF will contain the upper 
signaling tone. The limiters that follow convert the signals to square 
waves. Hence, at this point, there are two square waves, one out of 
each limiter. 

These signals now pass through bandpass filters centered at the two 
signaling frequencies. The square wave out of the low frequency limiter 
passes through a filter centered at the low frequency and a sine wave 
output is produced. The same occurs for the upper frequency square 
wave. Following the filters are threshold detectors that detect the sine 
waves if they are above a certain threshold level. The limiter employs 
a feedback arrangement to control the limiter operating threshold. 
The two detector outputs are combined to produce a logic output that 
is timed by the receiver’s tone validation circuitry to determine the 
denomination of the coin. 

Wherever possible, components originally designed for TOUCH- 
TONE signaling are used for design implementation. These include 
the limiter-threshold generator circuit module, STAR (standard tan- 
talum active resonator) filter circuit modules similar to those for 
TOUCH-TONE signaling, and the detector modules. These circuit 
modules are hybrid integrated circuits. The analog tone detector 
circuitry occupies two 4- by 8-inch printed wire boards. The filters are 
on one board, and the remaining detector circuitry is on the other. 

Tone validation timing is done digitally, with the circuitry consisting 
primarily of small scale integration (Ss1) and medium scale integration 
(MSI) TTL devices. A 1-kHz clock signal synchronizes all tone validation 
timing operations within the receiver. This clock sets the rate at which 
the tone detect signal from the analog circuitry is sampled. Based upon 
whether the dual tone detector is high or low at the sample instant, 
the various gates, counters, flip flops, etc., are operated in accordance 
with the tone timing validation algorithm. This tone validation cir- 
cuitry takes up four circuit packs, making a total of six packs for the 
entire receiver. Subsequent to deployment of the random logic timing 
circuitry, a cost reduction was made by having a microprocessor 
perform the timing algorithm. The entire tone timing validation circuit 
was placed on one circuit pack, lowering the overall circuit pack count 
to three. 


2.3 Automated testing of announcement and coin detection circuits 


The use of digital speech storage and PROCON control in SsAs made 
it possible, with a very small amount of added hardware, to provide 
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automated testing of the speech decoding and coin tone receiver 
circuits. 

The adaptive delta modulation decoding circuits in the CDAs are 
tested by using four single frequency tones digitally stored in the 
announcement store. Three of the tones are within the frequency band 
of the voice announcements, and the fourth is just above that band. 
The three in-band tones verify the flatness of response of the decoder 
and the transmission network associated with it. The out-of-band tone 
verifies correct roll-off response of an active low-pass filter included in 
each cpDA to filter out the 31,250-Hz “stairsteps” that result from the 
decoding process. 

Under control of a diagnostic program, each CDA is periodically 
taken out of service, and the digitized test tones are distributed to it 
from the standby ssas controller frame. The TspPs processor simulta- 
neously sets up a network connection from the output of the CDA 
circuit under test to the cpa test circuit. The cDA test circuit connec- 
tions for decoder testing are shown in Fig. 7. The cDA test circuit 
contains a bandpass filter that passes all the test frequencies, followed 
by a level detector that delivers “go/no-go” responses to indicate when 
the detected levels are in or out of tolerance. Also included in the cDA 
test circuit are four active “notch” filters followed by a detector and a 
smoothing filter. The notch filters remove the fundamental of each 
test frequency, and the detector responds to the residue, which includes 
harmonics and noise resulting from the adaptive delta modulation 
encoding/decoding process. The detector delivers a logic level “no-go” 
output if the residue is higher than normal. The smoothing filter is 
needed because, after the fundamental has been removed, the residual 
combination of harmonics and decoding products is partly random, 
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Fig. 7—Testing cpa decoders. 
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and without smoothing it would cause occasional “false alarm’ re- 
sponses at the detector output. 

Testing cDA decoder circuits in the way described above verifies the 
integrity of the logic circuits and wiring that retrieve and distribute 
digitized speech segments, and it checks for continuity and proper 
alignment of the voice frequency transmission apparatus that connects 
the cDAs to the Tsps trunks. 

The coin tone receivers are also tested by using tones stored in the 
announcement memory. The diagnostic program for the coin tone 
receivers directs the digitized coin test tones to a CDA decoder circuit 
pack that is dedicated for this purpose. The output of this decoder is 
routed through a solid-state switch controlled to produce tone bursts 
that simulate the coin station output signals that represent nickels, 
dimes, and quarters. The tone bursts are passed through switchable 
attenuators and through Tsps network connections to each coin tone 
receiver in turn. CDA test circuit connections for coin tone receivers 
are shown in Fig. 8. 

A very comprehensive test sequence is applied to the coin tone 
receivers using the scheme described above. The coin test tones are 
recorded and stored with nominal frequencies and frequencies just 
inside and just outside the operating tolerances on both sides of the 
nominal frequencies. The solid-state switch is operated to produce the 
nominal tone bursts that check the receiver’s detection of the various 
nominal and edge band frequencies and a variety of non-nominal 
durations and sequences that exercise the receiver’s timing logic. The 
switchable attenuators control the levels of the tone bursts in the test 
sequence to provide verification that the coin tone receivers operate 
over the range of levels that result from coin station and transmission 
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Fig. 8—Testing cDA coin tone receiver. 
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loss variations. The test sequence for each coin tone receiver is com- 
pleted automatically in a few seconds. 

The cpa test circuit includes four circuit packs identical to a set of 
four used in each cpDA, and five additional packs unique to the test 
circuit. The cpDaA test circuit also has a self-test mode. In this test mode, 
the output of the tone generation and control circuits of the CDA test 
circuit are temporarily fed back to the input of the filter/detector 
circuits and a “wrap-around” test sequence is executed. 


2.4 Physical design considerations 


A complete ssAs installation includes two controller frames, two 
announcement store frames, from 2 to 15 pairs of frames containing 
coin tone receivers, announcement decoding circuits, voice frequency 
terminating sets and amplifiers. The coin tone receivers and announce- 
ment decoding circuits are mounted in service circuit frames (up to a 
maximum of 16 sets per frame) and the voice frequency circuits are 
similarly mounted in transmission frames. 


2.4.1 Controller frame 


The controller frame (Fig. 9) is a single-bay frame, 2-ft 2-in. wide 
and 7-ft high, using a 12-in. deep framework, as do most other TsPs 
frames. This frame is compatible with all other Tsps frames and 
requires no special hardware, mounting, or installation arrangements. 

The communication bus and interconnection unit at the top of the 
controller frame contains multi-pin terminal strips for terminating 
cables from connecting frames. The connections to the announcement 
store are also made through this unit. Transformers are furnished for 
connection to the Tsps buses. Bus connectorization for growth is 
provided, and is compatible with existing office arrangements. 

The logic unit in the upper part of the controller frame includes six 
levels of circuit packs and a control panel unit. Five-volt power and 
ground return for the circuit packs are provided by a double-sided, 
printed-wiring back plane for each of the six levels. Each level is split 
into two halves for power distribution. Five levels can accommodate 
up to 37 circuit packs on %-in. centers. The sixth level can accommo- 
date 28 circuit packs on 4-in. centers. A very large percentage of the 
backplane wiring is automated. The type of circuit pack used is a 
double-sided printed wiring board, 6 in. by 7 in. in size, with 80 pins. 
An example of this circuit pack is shown in Fig. 10. 

The control panel unit contains the various keys, lamps, and jacks 
for maintenance and frame control functions. 

The memory and control unit provides mounting arangements for 
the PROCON and its associated memory packs. Connectorized cables 
are provided within this unit and between parts of the logic unit. 
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Fig. 10—Controller frame circuit pack. 


The power converter unit contains +5 V and —12 V dc-to-de con- 
verters and fuses. These power units are pluggable for easy replace- 
ment. A +5 V load fuse and a pilot fuse are provided for each half of 
the circuit pack levels and for the memory and control units. 

The fuse panel unit contains —48 V and +24 V fuses, alarm relays, 
and power control relays. The —48 V is used to supply the dc/dc 
converters. The +24 V is used in the circuit packs that contain bus 
drivers. 


2.4.2 Service circuit frame 


The service circuit frame (see Fig. 11) is a single-bay frame, 2 ft, 2 
in. wide and 7-ft high, using a 12-in. deep framework. Each frame may 
contain as many as 16 cDAs. A maximum capacity SSAS installation 
would include 15 service circuit frames to hold 239 cpDAs plus one CDA 
test circuit. 

The service circuit frame uses multi-pin terminal strips and bus 
coupling transformers for terminating cables from other connecting 
frames. In addition, the unit is arranged to hold three levels of circuited 
packs. These packs are associated with the 16 cpAs and the circuits 
that provide switchable access to either controller frame. The +5 V 
power is supplied individually to each service circuit and to each of 
the group controllers. Printed-wiring back planes provide +5 V ground 
return for each pack. A large part of the unit wiring is automated. This 
unit is always wired for 16 circuits and is equipped by plugging in 
circuit packs as determined by traffic requirements. 


ACTS SSAS HARDWARE 1245 

















Fig. 11—Service circuit frame. 
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The control panel unit contains the various keys, jacks, lamps, and 
switches associated with maintenance and frame control functions. 
Each cpa is controlled individually. 

The power converter unit contains +5, +6, and —6 V dc-to-dc 
converters and fuses for the +5 V distribution. These power units are 
pluggable for easy removal. A +5 V load fuse and a +5 V indicator 
fuse is provided for each service circuit. 

The fuse panel unit contains —48 and +24 V fuses, alarm relays, and 
power control relays. The —48 volt is used to supply the dc/dc power 
units. The +24 V is used for bus drivers. 

Even-numbered frames and odd-numbered frames are fused from 
separate power distribution frames. 

Space for up to 16 coin-tone receivers is provided on all frames 
except the first frame of the subsystem, where the CDA test circuit unit 
replaces one of the coin-tone receivers. The coin-tone receivers are 
connected to their associated CDA circuits by plug-ended cables to 
facilitate growth and rearrangement due to changes in traffic patterns. 


2.4.3 CDA transmission frame 


Associated with each service circuit frame is a single-bay frame (see 
Fig. 12) containing voice frequency transmission equipment. 

Growth and rearrangements are accomplished with pluggable ap- 
paratus. 


2.4.4 Announcement store frame 


Associated with each controller frame is an announcement store 
frame (see Fig. 3) that provides storage for the digitally encoded 
announcement segments. 

The bus unit at the top of the store frame contains terminal strips 
for interconnecting cables from connecting circuits in the office. Trans- 
formers are furnished as part of this unit to connect to the TSPS 
processor store bus. Store buses are connectorized to facilitate growth. 

As mentioned earlier, two memory modules are required for Auto- 
mated Coin Toll Service. Additional memory modules up to a total of 
six may be added to provide storage for additional vocabulary words 
if required by future features. 
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Traffic Service Position System No. 1: 


Automated Coin Toll Service: Software 


By R. AHMARI, J. C. HSU, R. L. POTTER, and S. C. REED 


(Manuscript received December 28, 1978) 


The Traffic Service Position System (tsps) No. 1 operational soft- 
ware for Automated Coin Toll Service provides the logic which 
controls the handling of coin-originated calls served by the system. 
The partitioning of responsibilities between the Station Signaling 
and the Announcement Subsystem (ssAs) are illustrated. The main- 
tenance philosophy, fault detection, diagnostics, and fault recovery 
aspects of the ssas are described. The maintenance strategy is cen- 
tered on a multilevel fault detection scheme in which faults are 
analyzed and classified according to their degree of seriousness in 
affecting the SSAS operation. 


1. OPERATIONAL SOFTWARE 


Automated Coin Toll Service (Acts) is a feature of the Traffic 
Service Position System.’ A Station Signaling and Announcement 
Subsystem (ssas) has been added to TsPs to detect and process coin 
deposits and to construct announcements for coin sent-paid toll cus- 
tomers. 

The SsAS contains a programmable controller (a microprocessor), 
which has a Read Only Memory (Rom) for program and a Random 
Access Memory (RAM) for transient data. It also has a set of Coin 
Detection and Announcement circuits (CDAs). These circuits detect 
coin deposit signals from coin stations and decode digital speech 
phrases to produce analog announcements. The ssAs also has an 
Announcement Source and Distributor (ASD) which contains an an- 
nouncement memory with digitally encoded speech phrases (see Fig. 
1). Commands to the ssas are sent by the Tsps processor over the 
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Fig. 1—ssas configuration. 


Peripheral Unit Address Bus (PUAB). Replies to the TSPs processor are 
sent over the Scan Answer Bus (SCAB). 


1.2 Functional description of ACTS call processing 
1.2.1 Initial call setup 


When the Tsps call connections program* receives a report of an 
incoming trunk seizuret from the supervisory scan program, it estab- 
lishes the required network connections for called digit and calling 
digit reception. (The latter is for Automatic Number Identification 
[ANI] offices.) 

The ANI digit analysis program assumes control until reception of 
the calling party’s number is completed. 


* This program runs on the TSpPs main processor. 

+ The description that follows deals only with calls that originate on trunks on the 
base network. Calls that originate on the network of an RTA are also handled by the 
operational software but not described below. 
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When the calling party identification has been received, control is 
returned again to the call connection program. At this time, a general 
analysis is performed on the information obtained, and the call is 
marked as 0+, 1+, etc. The 1+ coin-originated calls are candidates for 
automated treatment. (Coin customers expecting to make deposits to 
pay for a station-to-station call will dial the call with a “1” prefix or no 
prefix.) 

1.2.1.1 Initial ACTS processing. The next step in processing the 
call is to determine whether the call can be automated. This is done 
by a program in the main TSPSs processor. 

Conditions for Automation. 1+ calls that satisfy the following cri- 
teria are candidates for automation during the initial contact on the 
call. 


(t) AcTs-Converted Trunk Group. The call must be on an ACTS- 
converted trunk group. Certain modifications are needed in the 
coin station to generate dual-frequency coin deposit tones 
which the Coin Detection and Announcement circuits can 
recognize. All coin stations served by a trunk group must be 
modified before any calls on that trunk group can be automated. 

(tt) Machine Ratable. The call must be machine-ratable; i.e., TSPs 
must receive or have in office data sufficient rating information 
to calculate the charges due on a call. 

(zz) Not a Postpay Coin Originating Station. The call must not be 
from a postpay station. Coins deposited at postpay coin stations 
cannot be returned. An operator must verify that the correct 
party or station has been reached before the customer makes 
any deposit. 

(tv) Not a Large Charge Call. The call must have an initial charge 

less than a certain threshold. Coin station hoppers handle only 

limited numbers of coins (24 nickels, for example). Operating 
practices instruct operators to make partial collections for every 
two to three dollars deposited if the call has large charges. 

Large charge calls require multiple collections. Hence, an op- 

erator is required to verify called party answer before any coins 

are collected. 

Automatic Number Identification. The call must have success- 

ful Automatic Number Identification. If an ANI failure occurs 

or the call is Operator Number Identified (ON1I), the call cannot 
be rated. An operator must key the calling number. 


~~ 


(v 


Coin deposit monitoring on calls that fail condition (z) is not auto- 
mated but is handled by operators using current procedures. However, 
notification at the end of the initial period can be automated on all 
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coin calls, even if dual-frequency oscillators are not installed in the 
coin stations. 

Calls that fail conditions (22), (ziz), or (tv), as well as person-paid, 
coin-originated calls (which are dialed as 0+ calls), seize a position for 
the required operator assistance. If the trunk group is ACTs-converted, 
a Coin Detection and Announcement circuit is attached to assist the 
operator in counting deposits. Subsequent deposit monitoring for 
overtime can be fully automated unless the large charge threshold is 
exceeded. 

Calls that fail only condition (uv) seize a position for the purpose of 
acquiring the calling number. After the number is keyed in by the 
operator, further handling of the call is automated. 

If the above conditions for automation are met, the call connections 
program seizes an idle Peripheral Order Buffer (PoB) and transfers 
control to the network control program which loads the PoB with 
orders to establish a connection between the calling customer and a 
Coin Detection and Announcement circuit. If a CDA is not available, 
the call connections program seizes an idle PoB and transfers control 
to the network control program which loads the POB with orders to 
establish a connection to both a position and an outpulsing circuit. 
The call is subsequently handled as a non-AcTs coin call. 

sSsAS Processing of Initial Deposit Requests. Processing in the SSAS 
begins when the Programmable Controller (PROCON) receives an initial 
deposit request command from the TSPs processor. The command is 
read by PROCON from the ssAS input registers. The command message 
includes the number of the CDA handling the call, the initial duration 
of the call, and the amount to be requested from the customer (see 
Fig. 2). For purposes of illustration, assume the charge is $1.15 and the 
initial period is three minutes. 

The command field of the message is used as an index into a transfer 
table. The PROCON transfers to the address retrieved from the table. 
That program records the call data in the ssas data RAM, sets the 
initial state indication for the call, and sends an output command to 
initialize the CDA circuit. 

The PROCON next initiates scanning of the CDA circuit for coin 
deposits. The PROCON will continue scanning the CDA circuit at least 
once every 250 ms for the duration of the initial deposit phase of the 
call. The PROCON also instructs the SSAS announcement control cir- 


19 17 13 12 8 7 0) 
woRD1{| ——S&YsSs INITIAL PERIOD COMMAND CDA CIRCUIT NO. IRA 
12 9] 8 0 
WORD 2 CREDIT CHARGES IRB 
Fig. 2—Typical ssas input message from Tsps processor. Message is in format as sent 
from TSPS processor (two 20-bit words). 
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cuitry to send the first segment of the appropriate announcement 
phrase to the cDA circuit. It sends subsequent commands for successive 
portions of the announcement every 512 ms. The announcement used 
for the call being described is: 


“One dollar and fifteen cents,* please.” (2-second pause) “Please 
deposit one dollar and fifteen cents* for the first three minutes.” 


If the customer deposits during the announcement, the CDA circuit 
instantly inhibits the announcement. When the PROCON scans the CDA 
circuit and recognizes the deposit, it ceases sending further announce- 
ments, adds the value of the coin deposit to the previous amount 
deposited, and compares the total with the amount due. Assuming a 
sufficient deposit has not been made, the PROCON begins timing. If the - 
customer fails to deposit within five or six seconds, a prompting 
announcement is provided indicating the amount still to be deposited. 
For example, if the customer deposits three quarters in the above 
example and then stops, the prompt is: 


“Please deposit forty cents more.” 


If the initial deposit announcement completes without a deposit, 
timing will begin at that point. If the customer has made no deposits 
and a time-out occurs, the announcement wording for the prompt is: 


“Please deposit one dollar and fifteen cents.” 


Each deposit made causes the PROCON to reset its software intercoin 
timing register for the call. 

The PROCON will report the final results of the initial deposit request 
to the TsPs processor by loading a message into the SSAS output FIFO 
buffer (see formats in Fig. 3). There are basically three situations 
possible. 


(t) If the customer has failed to deposit within five to six seconds 
after a prompt, the PROCON sends a reply (Fig. 3, format B) to 
the TSPs processor indicating this fact so an operator can be 
connected to provide assistance. 

(ut) If the customer deposits the exact amount requested, the PRO- 
CON sends reply format A which contains the amount deposited. 

(zit) If the customer overdeposits by using too large a denomination 
coin, the PROCON sends reply format A. (The TSPs processor 


* The announcement format varies slightly, depending on whether the charge involves 
a dollar amount, a cents amount, or both. 
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FORMAT A a AMOUNT DEPOSITED CDA CIRCUIT NO. 
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REPLY CODE CDA CIRCUIT NO. 


Fig. 3—Formats of ssas output FIFo buffer. 


FORMAT B 


~ ~ 
°o Oo 


recognizes the overdeposit and records a credit towards over- 
time.) . 


The PROCON acknowledges the latter two cases above by initiating 
announcements. If the exact amount is deposited, the announcement 
is: 


“Thank you.” 


If an overdeposit has been made (for example, $1.25 on the $1.15 
call described above), the announcement is: 


“Thank you, you have ten cents credit towards overtime.” 


The PROCON continues to scan the cpa for further deposits until the 
acknowledging announcement is completed and sends a final deposit 
report to the TsPs processor at the end of the announcement. (This 
ensures credit for a belated deposit.) Finally, the PROCON places the 
CDA and the associated call memory in the ssAs data RAM in the idle 
state. The PROCON performs no further action on the CDA until a new 
command is received from the TSPs processor. 

At any time during the processing described above, the TSPs proces- 
sor can send a special command which causes the PROCON to idle the 
CDA circuit and associated call processing memory. (One example of 
this happening is if the customer hangs up.) 

Successful Initial Seizure. Upon receipt of the reply from SsAs 
indicating an exact deposit or overdeposit, the call is processed to 
completion. The call connections program seizes an idle POB and 
transfers control to the network control program which loads the PoB 
with orders to connect an outpulsing circuit. If an outpulsing circuit is 
not available, the call connections program queues until the circuit is 
available. The call connections program loads the orders to perform 
the appropriate relay operations required to complete the connection 
and activates the pos. Upon successful PoB completion, control is 
returned to the call connections program where the PoB is idled. The 
outpulser loading routine is called next. It loads the digits to be 
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outpulsed in an outpulsing register and activates sender-attached 
scanning for the receipt of a sender-attached signal from the toll office. 
Outpulsing of the called number to that toll office proceeds as described 
in Ref. 2, page 2658 ff. 

Receipt of called party answer and call timing also follow the 
description in Ref. 2. 

Operator Assistance on Automated Initial Seizure. If the customer 
fails to deposit in response to prompting by the ssas or flashes the 
switchhook* to acquire operator assistance, the customer will be 
connected to an operator. This section discusses the display presented 
to the operator, the operator actions, and potential race conditions. 

If the call must queue for a position, it is given “recall priority” to 
minimize customer delay. The Coin Detection and Announcement 
circuit is connected to the calling customer during the queuing interval. . 
If the call is being sent to a position because of a time-out and the 
customer subsequently satisfies or exceeds the charges while queuing 
for a position, the ssas informs the Tsps processor, the call is removed 
from the position queue, and outpulsing is initiated without operator 
assistance. When the call reaches the position, the following keys and 
lamps on the operator console (see Fig. 4) are lit steadily. 


The loop access key (Acs) 

The appropriate supervision lamps (CLD), (CLG) 
The station coin lamp (STA) 

The AMA station-paid key (PAID) 

The release forward key (FWD) 


The lighting of the AMA station-paid key and the release forward 
key indicates to the operator that an ACTS time-out or a customer 
switchhook flash has occurred during an ACTs initial contact. 

In addition to the above, an acTs underdeposit display is given to 
the operator (see Fig. 5). The “charge-minute” designation strip is lit 
steadily and the numeric field contains, from left to right, up to three 
digits for charges due, one digit for the initial period and up to three 
digits for the amount due. 

While the call is attached to a position, the operator assists the 
customer in making a full deposit. The operator must announce the 
amount due (the right-hand quantity) in the numeric field. The cpa 
circuit monitors and counts the coin deposits. The numeric display is 
not automatically updated with each coin deposit. However, the op- 
erator can update the display by using the charge and minutes (CHG- 


* For a time-out, the ssas indicates the request for an operator by a message. For a 
flash, the TsPs processor initiates the request. 
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ACTS — UNDER DEPOSIT _- 7 AMOUNT DUE 


UW ts|IUUBIUIUG! 





CHARGE MINUTES 





Fig. 5—tTsps No. 1 console numeric display. 


MIN) key. (The ssas will be interrogated for the current amount 
deposited and the appropriate display presented.) 

When the SSAS recognizes that the deposit request is satisfied, the 
TSPS processor is informed. The forward number is outpulsed and the 
correct display is presented to the operator (see Fig. 6). 

The operator receives several indications that the deposit is satisfied: 
outpulsing occurs, the amount due display changes to zero, the release 
forward key darkens, and the start key lights during outpulsing. 

After acknowledging the deposit, the operator depresses the start 
timing* and position release keys. 

At position release, the TsPs processor requests the amount detected 
by the cDA circuit. Upon receipt of the report, the CDA circuit is 
disconnected from the call. This final report accounts for all money 
deposited (while the CDA was connected to the call) so no late deposits 
are missed. 

If an overdeposit occurs, the numeric display is changed to an 
overdeposit display (see Fig. 7). This display has a flashing “charge- 
minutes” designation strip and a numeric display of zero in the charge 
field, blanks in the minutes field, and two digits having the overdeposit. 
The operator informs the customer that credit will be given towards 
subsequent overtime charges on the call, depress start timing, and 
position release. On subsequent deposit requests, the overdeposit is 
automatically subtracted from the charges due. 

1.2.1.2 Coin notification. At the end of the initial period, coin sent- 
paid customers are notified. With acts, this no longer requires an 
operator. The description below applies to coin sent-paid calls from 
both Acts and non-AcTs converted stations. 

TSPs Processing of Coin Notification. When a call reaches the 
talking state, it is under the control of the disconnect program. The 
call is placed on a timing list when the called answer has been 
established. A time-out occurs 7 seconds prior to the end of the initial 
period. Subsequent to this time-out, a coin collect sequencey occurs 


* Timing on the call is initiated by the Tsps processor only if the called customer 
answers. 


+ The coin collect sequence does not occur on postpay coin stations. 
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Fig. 7—Tsps No. 1 console numeric display. 


and the call is returned to the timing list for the remainder of the 
initial period. 

At the end of the initial period, the disconnect program seizes an 
idle Peripheral Order Buffer (PoB) and transfers control to the network 
control program which loads the Pos with orders to establish a 
connection between the calling customer and a Coin Detection and 
Announcement circuit. 

SSAS Processing of Coin Notification. When the PROCON receives an 
input message requesting an end-of-initial-period notification on a coin 
call, the data accompanying this command are the CDA number and 
the time of the initial period. In response to this command, the PROCON 
directs the SSAS announcement control circuitry to give the following 
announcement: 


“Three minutes has ended, please signal when through.” 


(A three-minute initial period is used for this illustration.) No coin 
scanning is performed, as no deposits are expected. After the announce- 
ment, the cpa hardware and software are idled and an announcement 
complete reply code (Fig. 3, format B) is sent to the TSPs processor. 

1.2.1.3 Charges due seizures. The Acts procedures for fully au- 
tomating overtime charges due seizures on coin-paid calls are presented 
in this section. 

Conditions for Automation. The ssas can fully automate overtime 
charges due seizures on coin-paid calls on an ACTs-converted trunk 
group even if the initial contact requires an operator. Since the call is 
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already rated, no rating or calling number identification (ANI) restric- 
tions apply to overtime seizures. Furthermore, charges due seizures for 
postpay calls are handled in the same manner as calls from other coin 
stations. However, there is one additional restriction on charge due 
seizures. All previous deposit request seizures (either initial contact or 
charges due) must have been successfully monitored by a CDA circuit. 
Successful monitoring implies that CDA circuit blocking did not occur 
and that the cDA circuit did not malfunction. This condition ensures 
that overdeposit credits are not lost. (If a seizure is not monitored 
successfully and an overdeposit occurs, the credit is not recorded.) If 
successful monitoring does not occur, the call is processed by an 
operator using current practices. In summary, the conditions for au- 
tomating overtime charge due seizures are: 


(t) The calling station is on an ACTS-converted trunk group. 
(tt) The charges do not exceed the large charge threshold* (see 
Section 1.2.1.1). 
(zzz) All previous seizures were successfully monitored. 
(tv) CDA must be available. 


If a call continues for a certain number of overtime intervals (usually 
10) and all the conditions for automation are satisfied, the SSAS 
automates the changes in seizure. Additional intermediate deposits are 
requested at successive specified overtime intervals until the call 
terminates. Then the sSAs automates the final charges due seizure at 
the end of the call. The collection sequences for end-of-call deposits 
and intermediate deposits are essentially the same. Furthermore, these 
collection sequences are very similar to those used for the initial 
contact on station (1+) calls (Section 1.2.1). 

With only a momentary interruption to the conversation path, TSPs 
connects an idle CDA circuit to the call. Tsps informs the ssas of the 
amount due, the number of minutes which have elapsed, the CDA 
circuit being used, and that it is a charge due seizure. 

SSAS Processing of Overtime Deposits. SSAS deals with the two 
overtime situations (end of call and intermediate overtime deposits) in 
a similar fashion. After receiving the command from the TSPs proces- 
sor, the PROCON processes the call in a fashion similar to the initial 
deposit case and the reports returned to TsPs are also similar. However, 
the TSps sends the amount of credit from previous deposits (if any) 
and the time sent is the elapsed overtime talked (in minutes), not the 
initial period. The announcement wording is also different. Assume 
that the call has progressed for five 25-cent overtime periods of two 


* The office data provided for the initial-period large-charge threshold is also used to 
specify the overtime large-charge threshold. 
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minutes duration each and that the customer had no credit. The 
announcement would be as follows: 


(Alerting tone) “Please deposit one dollar and twenty-five cents.” 
(0.5-second pause) “One dollar and twenty-five cents for the past 
ten minutes.” 


If the customer had a ten-cent credit, for example, the announcement 
is altered. 


(Alerting tone) “One dollar and fifteen cents please.” (2-second 
pause) “You have ten cents credit. Please deposit one dollar and 
fifteen cents more for the past ten minutes.” 


In the intermediate overtime deposit case, both customers are on — 
the call and intend to continue talking. They both can hear the 
announcement and talk during the deposit interval. In the end-of-call 
overtime case, only the calling customer is on the call. 

As with the initial deposit situation, if a customer stops depositing 
coins, a prompting announcement is given. Failure to respond to this 
announcement results in a report to TSPS requesting an operator. 

Operator Assistance. If the call times out or the customer flashes 
the coin station switchhook during the charges due phase of a call, an 
operator is connected to the call. The following keys and lamps on the 
operator’s console are lit steadily: 


(t) The loop access key (Acs). 

(tt) The appropriate supervision lamps (CLG, CLD). 

(iui) The appropriate coin lamp (STA, 0+, or Dial 0). 

(tv) The appropriate AMA key (station paid or person paid). 
(v) The charges due (CHG-DUE) lamp. 


These are the same keys and lamps lit by TsPs on charges due 
seizures prior to ACTS. In addition to these keys and lamps, the Acts 
underdeposit display, previously described for initial contact, is lit on 
the operator’s console. The appearance of the AcTs underdeposit 
display indicates two things to the operator. First, a CDA circuit is 
attached to the call to monitor the deposits. Second, if the customer 
overdeposited on a previous seizure, the charges displayed have been 
corrected by the amount of credit. (Note that, on non-ACTs charge due 
seizures, the operator must subtract any credit claimed by the cus- 
tomer from the charges displayed.) 

The operator assists the customer until a full deposit is received. 
When the sSAS recognizes that the deposit request is satisfied, the 
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correct deposit display is given. The operator thanks the customer and 
depresses position release. Upon releasing the position, TSPS requests 
the amount detected by the cDA circuit. After TSPS receives this 
information from the SSAS, the CDA circuit is disconnected. 

If the customer overdeposits during an overtime collection with an 
operator attached, the overdeposit display is lit on the operator’s 
console. If this is a charges due seizure for intermediate collections, 
the operator should inform the customer that credit will be given on 
subsequent overtime charges. If the overdeposit occurs at the end of 
the call, the operator should handle the disposition of the overdeposit 
in accordance with current operator practices. 

If the calling customer hangs up during the acts charge due an- 
nouncement sequence, or the calling customer leaves the phone off- 
hook, the operator should try to reach the calling customer, if neces- 
sary, by ringing back against off-hook. The operator may need to wait 
for the customer to return. If the operator is unable to obtain full 
payment for the call, the operator keys a walkaway trouble number. A 
traffic counter is pegged, and a special bit and the amount of shortage 
is recorded on the AMA tape. 

Even after the decision is made to go to an operator, the CDA circuit 
still monitors coin deposits. If the deposit is satisfied before the 
Peripheral Order Buffer (POB) which connects the position is activated, 
the position seizure is aborted. The ssas acknowledges the deposit, 
and the call is released. 

If the position is seized and then the deposit is satisfied, the SSAs 
does not acknowledge the deposit. When the operator’s numeric dis- 
play is lit, it shows (or may quickly change to show) that the deposit 
is satisfied. The operator should acknowledge the deposit and release 
the call. 


1.2.2 Non-coin features 


The announcement without coin detection mode of operation is used 
to provide announcements for time and charges quotations and noti- 
fication on calls other than coin sent paid. A different command is 
used in each case to select a different announcement. 


1.2.3  SSAS as a coin detector 


The PROCON is also programmed to provide a mode of operation in 
which it gives no announcements but does monitor for coin deposits. 
This is used on operator-handled ACTs calls. In this mode, the PROCON 
informs the TSPs processor when the required deposit or an overdeposit 
has been made. If the operator collects or returns coins while a call is 
in this state, TSPs informs the SSAS so the PROCON can appropriately 
update the amount deposited and the amount due in its data RAM. If 
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the operator requests that the amount deposited be displayed, the 
SSAS will transmit that amount to the TSPS processor in response to 
the appropriate command. 


1.2.4 Coin station maintenance and administrative features 


One unique aspect of ACTS operation is that inband signals (the coin 
deposit tones) are transmitted directly from the station through to the 
TSPS over the voice path. Two special features were developed that are 
related to coin tone signaling. First, a coin station test capability was 
developed which allows a craftsperson at the station to test that coin 
deposits for that station can be detected at the Tsps. Second, a 
precutover mode of operation was devised to help detect stations that 
have not been converted to be compatible with acts. These features 
are described below. 

Coin station test call. After the craftsperson has performed the 
usual coin station tests, the TSPs is accessed by dialing a special test 
code. When TSpPS receives this number, it connects the call to an idle 
CDA and sends a message to the SSAS with a command code indicating 
that this is a station test call. The remainder of the call is handled by 
the SSAS except that TSPs supervises the call. If the craftsperson goes 
on-hook, the Tsps aborts the call by sending a command to ssas. Also, 
TSPS will return coins on request from the SSAs. 

When the PROCON receives the station test call command, it initial- 
izes the CDA, begins coin scanning, and initiates the following an- 
nouncement: 


“Coin Test.” (1-second pause) “Please deposit nickel.” 


If the craftsperson deposits a nickel, the announcement, 


“Nickel” 


is given, acknowledging the deposit. A dime and quarter deposit are 
also requested and acknowledged. Then, the craftsperson may make 
additional deposits which will be acknowledged if received correctly. 
If no coin is deposited for about six seconds, the deposit request is 
repeated. If the wrong coin is deposited, a coin return is requested by 
the PROCON and the test is repeated. If repeated requests for deposits 
are not satisfied or a total of two minutes elapses on the call, the 
PROCON issues instructions for the announcement. 


“Test has ended.” 


and reports the time-out to the TsPps, which gives a coin return and 
disconnects the call. 
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1.3. PROCON program design 


The PROCON has relatively high processing capacity. It has a rela- 
tively powerful instruction set which is largely at the assembly lan- 
guage level rather than the microprogramming level, and it manipu- 
lates a 16-bit word. It uses a paged program memory and can execute 
instructions within a page in arbitrary, fixed order. (The next inter- 
page address (displacement) is specified in each 24-bit instruction.) 
Because of this characteristic, care must be exercised in relocating 
code to avoid improperly crossing a page boundary. (Such errors are 
detected during compilation.) 

The PROCON’s 16K program memory limit requires that the pro- 
grams be very compact. While an attempt was made to use modern, 
structured, design and documentation techniques, the limited memory 
size caused compromises in some areas. (The SSAS application requires 
a far larger program than most PROCON applications.) 

Multiprogramming was achieved by storing all call- (process) related 
information in the data RAM. Each program retrieves all data from 
that memory when it begins processing a new call. Each program is a 
pure process stored in ROM (i.e., the program contains no variable data 
and cannot alter itself). 

The PROCON has very extensive self-checking features. In addition 
to a variety of parity checks (including next address parity), the 
arithmetic and logic circuits are duplicated and checked by matching. 


1.3.1 PROCON program administration and design standards 


Several designers developed separate programs which were inte- 
grated into one large program. Loading was accomplished by using a 
linkage editor and a common file of symbols and macros. All symbols 
(except labels) and all macros were defined in the common file. No 
numerical references were permitted, and input/output control desig- 
nation symbols were keyed to the circuit drawing names for the same 
leads. Thorough prologue comments were required for each routine. 
Standard labels and standard symbolic designations and usage for all 
PROCON internal registers were agreed upon by all programmers. 


1.3.2 PROCON active monitor 


The basic program loop for the PROCON in the active SSAS (i.e., the 
SSAS which is processing calls) is called the active monitor. The PROCON 
executes this program while looking for tasks to perform. In this loop, 
the PROCON first makes some maintenance checks and then reads a 
clock to determine if a new 512-ms period has begun. The 512-ms 
interval is called a base period. Its length is keyed to the length of an 
announcement speech segment. If a new base period has begun, a 
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special flag is marked in the system status register.* The PROCON then 
scans for a message from the Tsps processor. If such a message has 
arrived, it records the data in the appropriate RAM area. 

The PROCON then begins a loop in which each CDA is processed. 
Each cpa has a dedicated eight-word call register associated with it. 
(Figure 8 is a typical CDA register layout.) First, the PROCON reads the 
address of the program which should process the call. This address, 
which also defines the state of the call, is called a Progress Mark (PM). 
If the po is zero, the CDA is idle or unequipped, so no action is taken. 
A typical PM program is the program which scans a CDA for coins. The 
PM is stored as a page number and a displacement within the page. 
The active monitor transfers to the PM routine. If the PM routine 
determines that the call requires timing, it checks the new base period 
flag. If that flag is set, the required timing counter is updated. 

When the pM program returns to the active monitor, the monitor 
checks the new base period flag. If that flag is set, all timing counters 
for the CDA are updated as required and a new announcement segment 
is selected. (The announcement processing is described in Section 
1.3.4.) After the announcement program is completed, the monitor 
processes the next cDA. When all cpAs have been processed, the 
monitor clears the new base period bit, checks for various maintenance 
tasks, and then begins the main loop again. 


7.3.3 Announcement store layout 


Each announcement speech segment consists of 16,000 bits of digital 
data stored in 400 consecutive announcement store locations. Each 
location contains 40 bits of data. Decoded at a 31,250 bits/second rate, 
this corresponds to 512 ms of speech. For programming ease and 
circuit design convenience, all segments must begin at an address 
which is a multiple of 16. Most words used fit in one segment (for 
example, the numbers “one” to “ten”). However, several words or 
phrases require two segments (for example, the word “eleven” or the 
phrase “please deposit”). A few phrases require three segments (for 
example, the phrase “please signal when through’’). 

Because the announcement circuitry bit-synchronizes segments, two 
or more segments can be blended together with no loss in quality. 
Therefore, words can be split between 512-ms segments to achieve the 
best cadence of speech. 

Successive segments constituting 1-second and 1.5-second phrases 
need not occupy consecutive announcement store addresses. However, 
these segments generally must be used together. In contrast, suffix 
segments used for compound numbers may be combined with a variety 


* One of the PROCON general registers was reserved for critical status indicators. 
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Fig. 8—cpa data RAM call register. 


of other segments. For example, the suffix ‘‘-teen” can be combined 
with the syllables “thir-,” “four-,” etc. to form the numbers “thirteen,” 
“fourteen,” etc. with minimal use of memory. Similarly, the units place 
suffixes “-one,” “-two,” etc. can be combined with the numbers 
“twenty,” “thirty,” etc. to form the full required set of numbers (e.g., 
twenty-one, twenty-two, thirty-one, thirty-two). 

Several words are duplicated in the announcement store so that 
both neutral and falling inflections are available. The falling inflections 
are used only at the ends of sentences, while the neutral inflections are 
used elsewhere. 

In total, about 80 speech segments 512 ms in length are required for 
acts call handling. About 15 more are required for maintenance 
purposes. 


1.3.4 Announcement table structures 


Two major announcement tables are stored in the PROCON ROM. The 
first is simply a table of addresses. Reading this table using the speech 
segment number as an index provides the address of the first an- 
nouncement store location containing the data for that speech seg- 
ment. 

The second table is more complex, as it controls the sequencing of 
announcement segments to form sentences. The logic for this process 
is embedded largely in this table rather than the program code. This 
makes debugging easier and also simplifies the process of adding new 
announcements. The table consists of program addresses for general- 
ized routines dealing with each step of the announcement. The address 
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of the current table entry is stored in the second word of the cDA 
register (see Figure 8). Each announcement routine must decide what 
speech segment is to be reproduced next and also update the table 
address in the CDA register. The major situations the various routines 
must deal with are demonstrated by the following example. 

The structure of a portion of a typical announcement is represented 
schematically in Fig. 9. This is the end of the time-and-charges 
announcement used for noncoin calls. A typical example of this an- 
nouncement follows. 


“The charges are one dollar and twenty cents plus tax for seven 
minutes.” 


The three major types of announcement routines are each involved 
in this announcement. One type of routine simply sequences speech 
segments in fixed order (for example, the words “plus tax for’). The 
second type of routine chooses a word or sequence of words (“one 
minute” versus “MM minutes”) based on the value of a parameter 
(whether M is one or greater than one). The third type of routine 
translates a parameter (M) into a speech segment (for example, the 
number “‘seven”) or a series of segments (for example, “twenty-one’’). 
This last program is a subroutine since the action to assemble the 
number is the same whether it represents a dollar amount, a cents 
amount, or a time period. 


il. MAINTENANCE 
2.1 Overview 
2.1.1 TSPS maintenance requirements 


In Tsps, as in other Bell System electronic switching systems, the 
maintenance strategy is based on duplicating vital hardware units’ and 
providing hardware checking circuits for other units, using signals to 
indicate the successful execution of orders and using programs to test 
the state of the hardware, to detect faults, and to diagnose trouble. 

TSPs provides fault recognition and diagnostic programs for all major 
circuit elements. The purpose of the fault recognition programs is to 
quickly detect faulty equipment units and, if necessary, remove them 
from service. Hardware checking circuits are used for trouble detection 


PLUS TAX FOR ONE MINUTE . 


MINUTES 


a 
HE 


Fig. 9—Typical portion of an announcement phrase. 
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during operation. When a trouble detection circuit identifies a serious 
problem in the system, it notifies an interrupt circuit. The interrupt 
circuit immediately stops operational program processing and transfers 
control to a fault recognition program associated with the particular 
trouble indication. The functions of the fault recognition programs are 
to distinguish nonrepeating troubles (errors) from repeating troubles 
(faults), and, in the case of faults, to quickly establish an operational 
system configuration. This is generally done by switching out the 
faulty unit. When the fault recognition process is completed, opera- 
tional program processing is resumed at the point of interruption. 

Fault recognition is the highest priority function in a real-time 
system like tsps. It is of the utmost importance to high system 
reliability that minimum time be taken away from the operational 
processing functions because of faulty circuits. 

Once the faulty circuit has been taken out of service by the fault 
recognition program and the system brought back to an operational 
configuration, diagnostic programs are called in to test the out-of- 
service unit to isolate the trouble to a small number of circuit packs. 
A diagnostic program is normally broken into logic testing entities 
called subphases or phases so that a series of rigorous tests can be 
performed on the out-of-service circuit unit. Depending on the outcome 
(pass-fail) of each test, a trouble-locating number is printed on the 
maintenance teletypewriter. This trouble-locating number is used by 
the maintenance personnel to reference a trouble-locating manual to 
isolate the particular fault involved. 


2.1.2 SSAS maintenance requirements and anticipated reliability 


SSAS reliability and maintainability objectives are based on the fact 
that a significant part of TSPs traffic is served by the ssas. The 
objectives are 


(t) An average of about one SSAS outage in 10 years. 
(iz) An average repair time of about 2 hours. 


The maintenance plan for ssAs impacts on the reliability objective 
in three major areas. First, it is necessary to provide fault detection 
mechanisms (primarily hardware checks) so all failures can be detected 
rapidly. Second, provisions must be made to minimize the interruption 
of call processing once a failure is detected, with few or no calls lost. 
Third, sufficient circuitry must be provided to obtain diagnostic reso- 
lution to hold repair time to the 2-hour average as specified above. 

The SSAS maintenance strategy relies on a multilevel fault detection 
scheme in which faults are classified according to their impact on the 
SSAS operation. A fault that does not affect normal operation of the 
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SSAS is considered “tolerable.” An ssas side with this type of fault may 
continue to perform its normal function adequately as long as it is 
required to do so. As an example, all single bit failures in the ssas 
semiconductor announcement memory are tolerated, since they would 
have very little effect upon the quality of the speech. By using a 
maintenance strategy that permits an SSAS side to be used with certain 
“tolerable” faults, the ssas reliability is further enhanced. 

To verify that the ssas design meets the reliability objectives, a 
reliability estimate was made by classifying and counting the boards 
on the SSAS side. The failure rate for each board type was calculated. 
The failure rate determines the Mean Time Between Failure (MTBF) 
of an unduplicated ssas side. The Estimated Downtime (EDT) for the 
duplicated system was then calculated with the assumption that the 
mean time to repair for one side down and both sides down are 
identical. This is a valid assumption because the diagnosis of all critical 
circuits in SSAS can be done on each side independently. Plugging 
necessary parameters into the appropriate reliability model showed 
that the above reliability objectives are well satisfied. 


2.2 Announcement Store Maintenance 
2.2.1 SPC bus and store switch 


The Stored Program Control No. 1A (spc 1A) is the TSPS main 
processor.* The sPc memory is used for both programs and data. It is 
partitioned into a maximum of 24 duplicated stores. Each store is 
permanently assigned to one of the two spc store buses. An SPC store 
can be equipped with a piggyback twistor (PBT) or semiconductor 
memory. Two sequential or complimentary name codes are assigned 
for an SPC store when equipped with semiconductor memory and one 
name code when equipped with pst. The name code serves to identify 
the stores for addressing purposes. A semiconductor store consists of 
a semiconductor memory module and its associated semiconductor 
memory controller, shared by all modules in the same memory frame. 
The spc store is the maintainable unit of SPc memory; i.e., it can be 
removed from or restored to service, diagnosed, and updated with the 
contents of its duplicate. 

The SSAS announcement memory is used to store digitized announce- 
ments. An Announcement Store Frame (ASF) is permanently assigned 
to each side of each ssas. The SSAS ASF consists of an announcement 
memory controller and up to six announcement memory modules. To 
simplify development effort and to take advantage of the memory 
loading facilities and diagnostic software of the spc, the spc semicon- 
ductor store frame with a second access port is used as the announce- 
ment store frame. This is accomplished by placing a switch on the 
announcement memory which allows the memory to be connected to 


1270 THE BELL SYSTEM TECHNICAL JOURNAL, JULY-AUGUST 1979 


either the SSAS side or the spc store bus. Furthermore, to reserve the 
maximum number of memory name codes for the sPc store, all spc 
memory access operations use odd parity name codes while all an- 
nouncement memory access operations use even parity name codes. 

Under the normal mode of operation, the switch is set to the ssas 
side so that access to the announcement memory can be performed. In 
the spc direct access mode, the switch is set to the spc side so that 
loading from the Program Tape Unit (PTU) and diagnosing by the spc 
can be accomplished. More discussion on loading and diagnostic op- 
erations is presented in a later section. 


2.2.2 The choice of announcement memory 


To handle all Tsps station-paid coin call announcements as well as 
time and charge quotations for noncoin calls, it was calculated in 1974 
that announcement capacity equivalent to about 80 half-second words 
would be needed. An ultimate memory capacity of 200 to 400 half- 
second words was forecast at that time if vocabulary for future features 
as well as space for other TSPS announcements were considered. 

A number of storage media were examined for the announcement 
memory. After some consideration, it was decided that with minor 
modifications the semiconductor memory used for the spc 1A store 
would also be suitable for the SSaAs announcement store. This choice 
of the announcement memory would provide flexibility in areas such 
as future vocabulary growth and vocabulary reload in the field from a 
magnetic tape. It was also estimated that most hardware and mainte- 
nance software designed for the spc 1A store could also be applied to 
the announcement store with only a modest amount of effort. 


2.2.3 Diagnostic implementation 


The spc store diagnostic programs were modified to be used for the 
SSAS announcement store diagnostic. Major objectives for the an- 
nouncement store diagnostic implementation were specified as follows: 


(z) Circuits common to both designs to be tested by existing spc 
semiconductor memory diagnostic programs. 
(tz) New announcement store circuits to be tested by the SsAs 
controller diagnostic. 
(zzz) Same Trouble Locating Manual (TLM) to be used for spc and 
SSAS announcement stores. 
(tv) Similar TTY input/output messages. 


Several diagnostic characteristics are common for the spc and 


announcement store diagnostic programs: the basic diagnostic unit is 
a controller and one memory module, seven diagnostic phases are in 
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the program, the diagnostic terminates on early detection of errors, 
there is a special bus configuration for increased fault detection, and 
finally, there are automatic exercise tests for all 32K words. For these 
common areas, existing spc store diagnostic programs were applied to 
the announcement store with only very modest modifications. 

On the other hand, some diagnostic characteristics pertaining only 
to the SSAS announcement store must be added to the existing store 
diagnostic programs. First, the announcement store has to be switched 
onto the standby spc store bus before it can be diagnosed. Second, 
since during normal operations, the PROCON and ASD circuits in the 
SSAS controller control the operation of the announcement store, they 
must be stopped during spc diagnostic tests. Third, the ssas controller 
and memory modules use even parity names while the SPC store uses 
odd parity names; consequently, diagnostic programs must be capable 
of distinguishing these two cases and proceeding accordingly. 


2.2.4 Loading store from program tape unit 


To save development effort, the spc program used to load from the 
Program Tape Unit (pTu),* compare with pTu tape, and dump the 
memory contents of the spc stores to a PTU tape is used to perform the 
same functions for the SSAS announcement stores. However, since 
there are some significant differences regarding tape format, loading 
procedures, and priority levels between the spc stores and the an- 
nouncement stores, some changes were made in the PTU program to 
extend its capabilities. 

The requirements for the handling of the tape unit are as follows: 


(t) The announcement information should be separate from office 
data and generic programs. A separate tape containing only 
announcement data should be used for announcement stores. 

(zt) For the load operation, the craftsperson must force one SPc bus 
active, simplex, before using the program to access the an- 
nouncement stores on the other bus. 

(zit) ‘The announcement tape header should be modified to distin- 
guish it from an SPC tape. 

(tv) spc reliability should be given the highest priority. The an- 
nouncement store should not be accessed if the spc is not able 
to run full duplex with all stores operational. 

(v) Changes must be made to minimize spc downtime resulting 
from undetected ssas store faults. 


With these requirements in mind, the craftsperson is instructed not 
to use the program to access the announcement stores if the SPC 
cannot run full duplex with all stores operational. With the spc fully 
operational, one bus may safely be forced active for the load operation, 


1272 THE BELL SYSTEM TECHNICAL JOURNAL, JULY-AUGUST 1979 


thus placing the system in the simplex mode. This choice of which bus 
to force active must be made such that the standby spc bus will 
correspond to the SSAS side requiring PTU actions. This procedure 
ensures that the announcement stores will never be placed on the 
active SPC bus. Following this line of conservatism, the announcement 
stores are normally switched off the standby spc bus and are connected 
just prior to a read or write instruction. After this instruction is 
completed, the stores are removed from the bus. 

The SSAS side to be accessed must first be placed in the out-of- 
service or unavailable state for the compare or dump option. If the 
operation is to load an SSAS announcement store with data from tape, 
the SSAS side must be in the unavailable state. This state will not allow 
SSAS side switching if a fault should be detected on the active side. 


2.3 SSAS fault recovery 
2.3.1 PROCON detected and reported faults 


SSAS fault recovery strategy is based on a fault detection scheme 
which uses both the spc and the programmable controller (PROCON) to 
detect various faults associated with the ssas hardware. Faults de- 
tected by PROCON are reported to spc. The decision to choose one 
method or the other was based on the following considerations. 


(t) SSAS faults, particularly those with serious impacts on call 
processing, should be detected as quickly as possible. 
(tt) SPC routine processing time required for detecting ssAs faults 
should be kept as small as possible. 
(tit) PROCON should not be responsible for detecting those faults 
which could affect its integrity or its ability to communicate 
with the spc. 


Those faults which are detected by PROCON are analyzed before 
being reported to SPC. PROCON has the capability to analyze available 
data and reinterrogate appropriate maintenance registers. If failures 
are Indicated, the result of analysis and reinterrogation are sent to the 
spc. The reports sent by PROCON are analyzed by the spc and, if 
necessary, appropriate commands are sent to PROCON to prevent it 
from flooding the spc with unnecessary information. 

2.3.1.1 Continuous exercises. Continuous exercise of hardware 
by PROCON is a means of verifying the correct operation of the hardware 
and detecting various failures. Exercises are used both on active and 
standby ssas sides, but these are particularly important on the standby 
side since no call processing is taking place. (Call processing exercises 
the ssas rather completely.) | 

The announcement subsystem” (i.e., the announcement store and 
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announcement distributor combined) is among those units which is 
continuously exercised by PROCON on both the active and standby 
sides to ensure the integrity of the speech heard by the customers. 
Any malfunction in these units would result in the appropriate flags 
being set in a maintenance register called the Error Summary Register 
(ESR). This register is periodically scanned by PROCON, which analyzes 
the content and sends the appropriate information to SPC. 

2.3.1.2 Announcement subsystem failure reports. PROCON can 
recognize failures associated with the announcement subsystem by 
scanning the Error Summary Register (ESR) periodically. The presence 
of any announcement subsystem failure will result in one or more flags 
being set in the EsR. If the content of EsR is different from its last look, 
PROCON sends a message to SPC indicating what trouble has occurred, 
provided PROCON has received no commands from sPc to stop sending 
information. 

During normal operation, a Hamming and parity check on the 
address and data received from the announcement stores is performed 
by hardware’ before the data are sent on to the service circuits. Once 
an error is detected, an error flag will be set in the Esr. The 67 bits of 
address, data, Hamming and parity for the error will be trapped in 
special maintenance address and data registers. 

The content of the EsR is scanned periodically by PROocoN. Upon 
identifying an announcement store error flag in the ESR, PROCON saves 
the contents of trap registers. Then it performs a read using the saved 
announcement store failure address. Subsequently, it loads the FIFo 
output register with the available information. This information in- 
cludes (see Fig. 10) the content of ESR, the content of failure trap 
address and data registers (both original and retry values), and an 
extended reply code used to distinguish the cases where no error is 
detected upon retry from those where error is also detected upon retry. 

Upon receiving a PROCON report, SPC analyzes the reported errors 
and decides whether a hard fault or a transient error is present. 
Detected errors and faults are categorized according to their types and 
seriousness. Types of errors and faults detected by spc are repeating 
double bit data fault, repeating single bit data fault, transient double 
bit data error, transient single bit data error, and repeating single bit 
address fault. The address and data associated with the errors and 
single bit data faults are also saved, and are printed hourly or upon 
manual request on the maintenance teletypewriter for manual trou- 
bleshooting. The failing address is also passed to the store diagnostic 
program to allow extensive tests of the suspected area of the memory. 

A feature that will aid in detecting announcement store errors is the 
announcement store recital program, which sequentially accesses every 
announcement phrase by loading its address into the maintenance 
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Fig. 10—Format of announcement subsystem failure report. 












time slot of a Recirculating Shift Register (RSR). This type of routine 
exercise will guarantee that the memory used by every speech segment 
is accessed periodically. If any store error associated with a particular 
speech segment exists, a flag will be set in ESR notifying PROCON of the 
error and the address and data associated with the errors will be 
trapped. This program is implemented on both active and standby 
SSAS sides. 

2.3.1.3 Mate frame buffer failure reports. Communication be- 
tween the two ssas sides (see Fig. 11) takes place asynchronously 
through a first-in, first-out serial memory called the Mate Frame 
Buffer (mFB). Each transmission through the MFB usually consists of 
data and an 1D field which identifies the data. 

During normal operation, all the data associated with the calls in 
progress are sent from the active side to the standby side through the 
MFB. This operation enables the standby side to have an up-to-date 
copy in its Random Access Memory’ (RAM) of the data associated with 
each call for use if it is required to change role from standby to active. 
To test the validity of the data before it is stored, a 1-out-of-16 encoded 
ID word is associated with the data coming through MFB, to indicate 
what it contains. The standby PROcON checks for a valid 1D format 
and for proper sequences of IDs. If the standby PROCON detects an 
error, it informs the spc by loading appropriate data in its FIFO output 
register. 


ACTS SOFTWARE 1275 


6Z6L LSNONV-AING “IWNYNOP IWOINHOAL WALSAS T14d SHL = 9Zeb 





BINARY ADDRESS BUS 








CBT 


SCAB 
eS 


OUTPUT INPUT 
REGISTER REGISTER 


ae nih 
PROGRAM 
0 ere eee 


SPC 

















INPUT 
REGISTER 


MATE 
BUFFER 
0 
MATE 
FRAME 


OUTPUT 
REGISTER 













BUFFER 








DATA 
ANNOUNCEMENT ANNOUNCEMENT RECEIVER 
MEMORY DISTRI Re | “I~ 7) t-------- 
0 ener ANNOUNCEMENT 
OUTPUT 


e 
e 
e 








DATA 
RECEIVER 


ANNOUNCEMENT 
OUTPUT 
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During the unloading of the MFB by the standby side, an overflow 
condition in the MFB results in an MFB full flag being set in the ESR 
associated with the active side. This overflow condition could be 
caused by either an MFB failure or a failure in the standby side which 
prevents it from unloading the Mrs. The MFB full flag in the ESR is 
monitored by the active PROCON. Upon detecting the MFB full condi- 
tion, the active PROCON notifies Spc by loading the necessary infor- 
mation in the FIFO output register. 

2.3.1.4 CDA error reports. A cDA failure is recognized by PROCON 
during normal interrogation. All calls except those that are in the 
announcement mode only require interrogating the CDA reply register 
for coin deposits. Prior to sending the first interrogation command to 
a CDA, PROCON reads the reply register to ensure that there are no 
premature replies from the cDA. In the case of premature reply, all 
records of the call are erased and a message is sent to SPC indicating a 
bad cpa. During the course of interrogation, the parity of the data 
received from the CDA is checked by PRocoN. In the case of a parity 
failure, PROCON again erases the records of the call and informs the 
spc of the failure. 

During the course of interrogation, PROCON continuously monitors 
the format and the validity of the data in the cDA reply register. A 
reply with invalid format is considered a CDA failure. In this case, the 
records of the call are also erased, and SPC is notified of the cpa failure. 
Another means of cDa error detection is the CDA maintenance register. 
If a maintenance bit is set in the reply register, the maintenance 
register is read to check the type of error. In this case again, PROCON 
notifies spc and erases the records of the call. Upon receiving a CDA 
error report from PROCON, SPC routes the call to an operator position 
and also takes the bad cDA out of service, so it is not used for any 
future call. A diagnostic automatically will be requested for the bad 
CDA to aid the craftsperson in locating the faulty units. If too many 
CDA failure reports are received within a certain period of time, all 
associated with the same group controller, spc then assumes that the 
group controller associated with the active side is faulty. 

PROCON can only detect failures in the digital circuitry of a CDA. 
Failures in the analog circuitry of a CDA are detected by an error 
analysis program which resides in spc. The success rate of attempted 
calls for a given CDA is analyzed, and if it is below a certain average 
threshold, the cpa is considered faulty and is taken out of service and 
automatically diagnosed. 


2.3.2 SPC detected and reported faults 


2.3.2.1 Maintenance interrupts. Maintenance interrupts are used 
as a means of identifying faults in spc-ssas interface registers. These 
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types of faults have a serious impact on the operation of ssas. They 
can result in isolation of the ssas, thus crippling the capability of spc 
to determine the basic integrity of the ssas. This basic integrity is a 
necessary condition for the spc to have confidence in the capabilities 
associated with PROCON in detecting ssas faults. 

As with other Tsps peripherals, any malfunction in SPC-SSAS com- 
munication is detected by using standard peripheral unit fault recog- 
nition techniques that can cause an F-level interrupt (such as central 
pulse distributor enable verify, and all-seems-well signal failures).‘ 
Upon occurrence of an F-level interrupt, appropriate fault recognition 
programs are entered to analyze the faults present in SPC-SSAS interface 
areas. These programs have the capability of distinguishing serious 
faults from nonserious faults and reporting them to appropriate recon- 
figuration programs. 

During a scan operation of SSAS by spc, a malfunction in one or both 
Scan Answer Buses (SCAB) results in an SPC processor mismatch which 
in turn causes a C-level interrupt to occur.‘ Upon occurrence of a C- 
level interrupt, appropriate fault recognition programs are entered 
which first determine whether SSAS caused the interrupt, and then by 
performing some tests isolate the faulty scAB. The nature of failure 
and its degree of seriousness are also passed to SSAS reconfiguration 
programs. 

2.3.2.2 Periodic scans. sPc detects faults in PROCON itself or in the 
PROCON peripheral control system by interrogating maintenance reg- 
isters on the scan answer bus. This interrogation is done periodically 
(every 25 ms). The information provided by this interrogation (scan) 
is used by the spc to determine the sanity of the PROCON for processing 
calls and to verify the capability of PROCON to detect ssas faults. 
Among faults detected by periodic scanning are PROCON all-seems-well 
failures, Random Access Memory (RAM) all-seems-well failures, 
PROCON clock-stopped and output register-full indications. Both active 
and standby ssAs sides are monitored by the periodic scanning. The 
scan result is analyzed and is used to distinguish serious faults from 
nonserious faults, and to determine whether or not an immediate 
action is needed by the spc. 

2.3.2.3 Dead side tests. Despite the fact that extensive error 
checking circuitry has been built into the ssas hardware, the possibility 
still exists that some faults may elude the checks and not be reported 
to the spc. Potential faults in this category are nonclassical faults, 
multiple faults, certain PROCON and RAM failures, etc. A possible 
consequence of such faults is a dead SSAS side which appears to be free 
of faults during a period of no normal SPC-SSAS communications. To 
detect such a failure mode, the spc performs an exercise periodically. 
The exercise involves sending a command to an SSAS side and receiving 
a specific reply. If an ssAs side fails to reply as expected, then the side 
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is considered to be faulty, and appropriate information is reported to 
the reconfiguration program. 

Since ssaAs functional integrity is constantly checked by call proc- 
essing functions, the dead side test for an active SSAS side will be 
skipped if traffic is present on the side. More specifically, an ssAs side 
will not be tested if valid replies are coming through its output register 
at a regular interval. 


2.3.3 Reconfiguration 


2.3.3.1 Classification of faults. The response of the SSAS recon- 
figuration program to various SSAS faults is based on a fault classifi- 
cation scheme which categorizes the faults according to their impact 
on the normal operation of ssas. Faults fall into one of four categories 
which can be summarized as follows: 


(t) Serious faults. This type of fault corresponds to those which 
seriously affect the call processing capability of ssas. For ex- 
ample, a fault which stops normal operation of PROCON is 
considered to be serious. A serious fault on an active SSAS side 
will cause an immediate switch to the other side. 

(tz) Nonserious faults. A nonserious fault is defined as a type which 
does not seriously affect the call-processing capability of an 
SSAS side. An active side with this type of fault can continue to 
perform its normal function adequately as long as it is required 
to do so. This in turn implies that the switching action to the 
mate side can be delayed indefinitely, if necessary. For example, 
a single bit failure on the announcement data can be considered 
nonserious since its impact on the quality of the announcement 
is insignificant. As another example, a group controller failure 
on the active side can also be considered nonserious, since the 
side can continue to process calls using the remainder of the 
group controllers and their associated CDAs. 

(tii) MFB faults. This type of fault is usually an indication of a failure 
in the MFB itself or the standby ssas side, with no impact on 
the active ssas side. No switching of sides is performed in this 
case. Instead, the standby side and MFB are both diagnosed for 
isolation of faulty units. 

(tv) CDA faults. This type of failure usually represents a problem in 
an individual cpA. Since there are many CDAs in SSAS, an 
individual cpDA failure does not have a serious impact on the 
call-processing capability of ssas. A faulty CDA is marked out 
of service and will not be used until it is diagnosed and repaired. 


2.3.3.2 Smooth side switch. The process of interchanging the 
active side and standby side is referred to as a side switch. If this is 
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done so that the flow of announcements is not interrupted, the switch 
is called a smooth switch. 

A smooth switch between two SSAS sides is performed under two 
circumstances. One case is when the active side has a nonserious fault 
such as single bit failure in announcement data. In this case, the 
system can afford to wait as long as needed to switch smoothly. The 
other situation is when a routine switch to the standby side is desired 
to test the hardware controlling the reconfiguration and to provide a 
chance to run a routine set of diagnostics on the previously active side. 
This process (the smooth switch exercise) is performed three times a 
day. 

A smooth switch is typically characterized by the following actions. 
First, the spc sends a command to the active side, telling it to go 
standby gracefully. Second, the active side brings the standby side in 
loose synch with the active. Third, the standby side is told to go active 
gracefully. Since by now the active and the standby are loosely in 
synch, both sides time themselves until the right moment when the 
old active goes standby followed almost immediately by the old 
standby going active. The new active verifies its success by sending a 
reply to the spc. Upon receipt of this reply, the spc changes the ssas 
status words to record the new configuration. This type of side switch 
does not provide any discontinuity in the announcement heard by the 
customer and also has no effect on the call processing operation. 

2.3.3.3 Other types of side switch. The handshaking between the 
two sides required to perform a smooth switch may not be possible if 
the active side develops a serious fault such as a PROCON all-seems- 
well failure. Assuming that the nonactive side is in the standby ready 
state, the Spc simply takes the faulty side out of service and makes the 
standby side active. This type of switch is referred to as an immediate 
switch. Since the standby’s data RAM is up to date with the active side, 
only a minor disruption to call processing results. The announcement 
heard by a customer is interrupted. Approximately a half-second 
elapses, and then the entire announcement is repeated. In addition, it 
may result in mishandling a single call. However, this minor disruption 
of the call processing is considered a small penalty, as hardware faults 
occur rarely. 

Another type of side switch, called a rough switch, happens when 
the active side is doing call processing and the nonactive side is running 
a routine diagnostic on itself. If the active side develops a serious fault, 
it is immediately taken out of service. In the meantime, the routine 
diagnostic on the nonactive side is aborted, and the side is made active. 
Since the data RAM on the standby side is not up-to-date while a 
diagnostic is being run, it will be initialized before becoming active. 
Therefore, all processing on existing calls is aborted and the ssas starts 
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afresh. Considering the reliability objectives of the ssas, the probabil- 
ity of occurrence of a rough switch is estimated to be very small. 

2.3.3.4 Tolerance of software errors. Software errors are usually 
analogous to a serious component failure, causing both SSsAs sides to 
go down and remain down until the problem has been rectified. 
However, certain classes of software errors could be considered toler- 
able. An erroneous software instruction which is executed infrequently, 
if it is considered to be nontolerable, could cause a permanent outage 
of the SSAs upon its first execution. On the other hand, if at this time 
the SSAS is reinitialized and restarted, it will continue to perform its 
normal function until some later time, when it will encounter its second 
failure, due to the execution of the erroneous software instruction. 
Following this strategy would substantially decrease the ssaAs down- 
time in cases where infrequently executed software errors are present. 

The above considerations provided the basis for developing a strat- 
egy which tolerates certain classes of errors in the PROCON software. 
Upon occurrence of an SSAS outage, the spc performs an analysis for 
both sides using past history of SSAS outages. First the side with the 
fewer past failures is selected. Then after the analysis a decision is 
made on the nature of the problem for that side, as to whether a 
hardware fault or a software error exists. In the latter case, the side is 
reinitialized and used for call processing after a successful initialization, 
while a diagnostic is requested for its mate side. In the former case, 
both sss sides are diagnosed to pinpoint the hardware malfunctions. 

2.3.3.5 Duplex failure. If ssas becomes totally unavailable, the 
call processing function performed by the ssas is aborted and all new 
calls will be routed to the operators. The new calls are blocked from 
attempting to cease CDAs for service. Also, several clean-up actions are 
performed by the spc to allow for rapid restoration of acts. For 
example the peripheral orders waiting to be sent to the SSAS are 
searched and disposed of. The ssas is blocked from providing AcTS 
until all the clean-up tasks are completed. 


2.4 SSAS diagnostics 
2.4.1 Controller diagnostic 


2.4.1.1 Interface SPC—PROCON. The ssas diagnostic programs 
run on one SSAS side at a time, always a nonactive side. The diagnostic 
request is made either by manual request or by fault recognition 
programs, either as a result of a fault being detected or as a routine 
diagnostic. The routine diagnostic is run once a day to do a complete 
check of the ssas hardware. 
As a direct consequence of the ssas architecture, the ssas diagnostic 
control is divided into two parts; the first part resides in spc, and the 
second resides in PROCON’s Read Only Memory (Rom) and is under 
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the control of a standby monitor program which controls the various 
activities of a nonactive SSAS side, including diagnostics. Other activi- 
ties associated with the standby monitor include fault recognition, 
unloading of the Mate Frame Buffer (MFB) and other spc-requested 
nondiagnostic functions. SPC retains the overall control over the ssas 
diagnostic. SPC initiates SSAS diagnostics by first marking the SSAS side 
out of service and then sending a diagnostic request to the PROCON. 
The request indicates that a group of tests referred to as a “phase” is 
to be run by PRocon. In some cases, this request is also accompanied 
by a test pattern to be used by PROCON. The standby monitor decodes 
the request, performs error checking, and invokes the PROCON diag- 
nostic control program. This program further decodes the diagnostic 
request to select the proper diagnostic phase. Once a diagnostic phase 
is initiated, the standby monitor exercises control over the execution 
of the diagnostic. A diagnostic phase performs tests on the SSAS 
functional block being diagnosed, using predetermined test patterns 
and sends the test results to spc through the FIFO output register. The 
test results are used by the spc to isolate the particular fault involved. 

2.4.1.2 Levels of raw data compression. The diagnostic test re- 
sults sent by PROCON through the FIFO output register are compared 
against the expected result by the spc. The result of that comparison 
is saved as a binary string of ones and zeros referred to as “raw data” 
results. The zeros represent the tests passed and ones indicate the 
tests failed. Although PROCON does considerable data comparison, in 
many diagnostic phases the test results sent by PROCON are quite 
voluminous and exceed the capacity of the trouble number generation 
programs. In such cases, SPC uses a compression algorithm for con- 
verting the test results into a compressed raw data bit string. The 
algorithm uses a simple procedure: If any test result word sent by 
PROCON does not match the expected value, the spc diagnostic program 
will map this mismatch into one raw data bit. The compressed raw 
data bit string is further reduced by the spc to a 4-part, 16-digit 
number referred to as a “fault signature,” which uniquely identifies 
the string. The fault signature is used by the maintenance personnel 
to reference a trouble-locations manual to isolate the particular fault 
involved. 

In some cases, the fault signature generated by ssAs diagnostic 
programs fails to provide enough information to clear the trouble 
associated with the ssas. In such cases, the maintenance personnel can 
manually request either compressed raw data or expanded raw data. 
The raw data printout is used by maintenance personnel as an aid in 
manual troubleshooting. 

2.4.1.3 Power of PROCON test. The ssas architecture has parti- 
tioned the hardware in functional modules (such as PROCON, peripheral 
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control, announcement memory, service circuit group controllers, 
etc.).” Each of these functional modules are further partitioned to 
attain the desired level of maintainability and diagnostic resolution. 

PROCON access to each functional module results in a simple diag- 
nostic structure consisting of segments that diagnose only one func- 
tional module. In general, diagnostic resolution is directly related to 
the size of the module’s diagnostic. Resolution can be improved by 
reducing the size of the module. A further improvement can be realized 
by choosing a diagnostic structure that begins with the diagnosis of 
the most basic functional module and proceeds to test each module by 
adding diagnostic segments that use the diagnosed modules. These 
considerations have been taken into account in planning the ssas 
diagnostic structure, which provides an average diagnostic resolution 
of three or fewer circuit packs, with the capability of detecting greater 
than 90 percent of potential ssas faults. These diagnostic objectives 
are required to limit the average repair time to about 2 hours as 
specified by the SSAS maintainability objectives. PROCON access capa- 
bility combined with the modular architecture allows the ssas diag- 
nostic objectives to be achieved. 

Another feature that helps to achieve the SsAs diagnostic resolution 
objective is the bit-sliced architecture used in designing SSAS input and 
output bus interfaces. The bit-sliced architecture is used to aid the 
SSAS diagnostics in pinpointing faulty packs and to reduce the number 
of board codes. This means that the common bits for all registers on 
a bus are grouped together on one or a few circuit packs (i.e., bit 7 for 
all registers on the bus are grouped together). Because of this archi- 
tecture, it is only necessary for the ssas diagnostic to know which bit 
is bad to isolate the faulty circuit boards. 


2.4.2 CDA diagnostic 


2.4.2.1 SPC-PROCON interaction. The cDA diagnostic is initiated 
by the spc either as a result of cDA failures detected by fault recognition 
programs, error analysis programs, or a manual diagnostic request via 
the maintenance teletypewriter channel. Also, an automatic progres- 
sion test of the CDAs is performed to ensure that each CDA is diagnosed 
once a day. 

A service circuit known as the CDA test circuit is used to diagnose 
cpAs. It has network appearances so it can be connected to the various 
CDA ports for analog circuit tests.” When a cpa diagnostic is requested, 
the spc attempts to establish a test configuration if the requested CDA 
is available for testing. It first verifies that the CDA test circuit is 
available and the nonactive SSAS side is in the standby ready state. If 
not, the diagnostic is blocked; otherwise, the cDa test circuit is made 
maintenance busy, and orders are sent to the active SSAS side to switch 
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both the cDA test circuit and the CDA under test over to the standby 
SSAS side. Next, the Signal Distributor (sp) controlled relays in both 
the CDA and cDA test circuits are released without regard to their 
previous states, and the two circuits are connected via the TSPs 
network. 

Once the test configuration is established, various phases of the CDA 
diagnostic are initiated by the spc. For each phase, the spc first 
operates the required sD-controlled relays, and then sends an order to 
the standby ssAs side to run tests of the specified phase. 

The PROCON standby monitor program processes the diagnostic 
order and transfers PROCON control to the cDA diagnostic program. 
This program performs the tests of the specified phase and sends the 
results to the spc via the FIFO output register. Once the PROCON reply 
is received, the spc compares the test results with the expected results. 
The result of this comparison is the diagnostic raw data. Each bit set 
to a one in the raw data represents a test failure. The raw data is then 
converted into a trouble number which is used by the maintenance 
personnel to isolate the trouble. 

When all the phases of the CDA diagnostic have been completed, the 
SPC releases the relays of the CDA and cDA test circuits, breaks the 
network connection between them, and sends orders to the standby 
SSAS side to switch them back to the active side. The cDA test circuit 
is returned to the maintenance idle state, and the CDA under test is 
either returned to service or placed out of service, depending upon 
whether the diagnostic tests have been passed or failed. 

2.4.2.2 CDA test circuit use. The CDA test circuit is a special type 
of ssas-controlled service circuit. There is one CDA test circuit per 
SSAS, and it is always equipped as circuit 15 of the service circuit 
frame 1. 

The primary functions of the CDA test circuit can be summarized as 
follows: 


(t) It produces simulated coin deposit signals for testing a CDA coin 
tone receiver. 
(zi) It detects test tones produced by a CDA announcement decoder. 


The cDaA test circuit architecture is quite similar to that of the other 
SSAS service circuits. It consists basically of digital circuitry to interface 
with SsAS, a tone generator and a tone detector (see Fig. 12). Its digital 
interface circuitry with ssas consists of command decoding logic, reply 
registers, and control logic which provides additional decoding of cDA 
test circuit commands, and also controls the miniature relays which 
provide switching of pads and filters. 

The tone generator consists of an announcement decoder, an inter- 
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Fig. 12—Block diagram of cpa test circuit. 


rupter switch, and a set of switchable attenuation pads. The interrupter 
switch is used to clamp the analog output of the announcement 
decoder to ground, thereby silencing the tone generator. The switch- 
able pads provide the level variation needed for a CDA coin tone 
receiver testing. 

The tone detector consists of a switchable pad circuit, level detectors, 
and a switchable filter circuit. The switchable pad circuit provides 
level adjustment for signals generated by a CDA announcement de- 
coder. The output of the announcement decoder of a CDA circuit is 
tested by the level detectors for both signal loss and distortion. During 
the process of checking for signal distortion, the switchable filter 
circuit is used to remove the expected fundamental frequency com- 
ponent of the announcement decoder test tone without attenuating 
any harmonic frequency components. 


2.4.3 Use of test tones from announcement store 


Many tests performed during the course of cDA diagnostic are aimed 
at detecting possible malfunctions in either the announcement decoder 
or the coin tone receiver associated with the cDA under test. Proper 
operation of the announcement decoder is verified by monitoring its 
response to a set of digitized test tones. This response is checked for 
possible abnormalities in both frequency response and output level 
using a tone detector associated with the CDA test circuit. The coin 
receiver is tested by using the tone announcement decoder of the cDA 
test circuit to produce coin deposit signals from data stored in the SSAS 
announcement memory, and checking the response of the coin tone 
receiver to deposit signals having various level, frequency, and timing 
characteristics. 

The test tones required for checking the proper operation of the 
announcement decoder and the coin tone receiver are stored as an- 
nouncement data. A total of 18 test tones are required for CDA diag- 
nostic tests. The storage requirement for many of these tones is 
significantly reduced by packing several of them into a single an- 
nouncement phrase. Combining up to four 125-ms test tones into a 
single segment reduces the number of the required segments to six. 
One hundred twenty-five milliseconds allows ample time for the an- 
nouncement decoder output to stabilize and for the cDA test circuit 
tone detector to achieve a stable measurement. However, this ap- 
proach adds additional timing functions for the standby PROCON to 
perform. PROCON must determine the appropriate time to strobe the 
tone detector and, for some tests, it must blank out the unwanted 
tones by operating an interrupter switch within the cDA test circuit 
which turns off the analog output of the tone announcement decoder. 
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2.5 CDA alignment and manual tests 
2.5.1 Trunk test panel connections 


The Tsps Control, Display, and Test (cpT) panel provides a means 
of manually initiating tests on trunks, operator positions, and service 
circuits appearing on the Tsps switching network.® In conjunction with 
the acts feature, provisions have been made for testing both the cDa 
and the cDA test circuits from the CDT panel. 

Most cDA circuit tests originating from the CDT panel require that 
test connections be established between the CDA circuit and the cDT 
circuit. Operation of the Master Test Line-Test key on the cpT panel 
causes the spc to connect an MF receiver to the Position Master Test 
Line (PMTL) of the CDT circuit via the TSPS network. Once this connec- 
tion is established, the spc lights the Master Test Line (MTL) lamp on 
the CDT panel, indicating that codes can be entered via the cpT 
multifrequency (MF) key set. At this point, a test connection can be 
requested with any CDA circuit appearing on the TsPps network by 
entering its trunk group and member number and the camp-on bit via 
the cpT MF key set. A special display on the cpT panel indicates to the 
maintenance personnel whether the request was successful, aborted 
due to system failure, or invalid. 

The spc indicates the status of the requested CDA on a special 
display lamp. This lamp indicates whether the cpa is idle, traffic busy, 
maintenance busy, or out of service. If the CDA is busy and camp-on is 
requested, the spc reserves it for maintenance by placing it out of 
service as soon as it becomes idle and notifies the maintenance person- 
nel of its availability via a teletypewriter output message. If the CDA is 
idle or out of service, the spc disconnects the MF receiver from the 
PMTL, extinguishes the MTL lamp, and establishes the test connection 
between the cDA and CDT circuits. 

Several other test features involving CDT panel key actions have also 
been provided for CDA circuits. By operating appropriate keys, the 
maintenance personnel can place the CDA connected to the cDT out of 
service, or return it to service. Also, a display of the ferrod states of 
the CDA under test can be requested by operating a special key. This 
key action causes the scan row containing the CDA ferrods to be 
displayed on the program display of the control and display panel. 


2.5.2 Trunk test panel measurements 


The cDA circuits contain analog transmission components which 
provide a part of the talking path between the customer or customers 
and the CDA announcement decoder. These CDA circuit voice paths 
must be tested with respect to noise and signal loss whenever trans- 
mission problems associated with the circuit are suspected. The trunk 
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test panel, shown in Fig. 13, provides a convenient means of performing 
noise and loss tests on CDA circuits that appear on the TSPS network. 

Testing of the transmission path of a CDA circuit involves separate 
tests for performing noise and loss measurements. First, a test connec- 
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tion is established and the Master Test Line-Test key is operated to 
signal the spc to connect an MF receiver to the PMTL. Next, by entering 
an appropriate test code and appropriate test control key actions, each 
of these tests can be initiated. These tests can be repeated or performed 
in any sequence as long as only one test control key is operated at a 
time. These tests can also be sequenced under the sPc control by using 
an appropriate test code. As soon as the code is entered, the spc 
establishes the connection for the first test. Upon completion of the 
first test, the connection for the second test is established. This process 
is continued until the completion of the last test. At this point, the 
CDA circuit is disconnected from the CDT panel and is returned to its 
previous state. 

Manual transmission tests of all CDA circuits in the office can be 
initiated by entering a special test code. The spc connects each CDA 
circuit in sequence to the cpT panel. If the circuit is traffic or mainte- 
nance busy, it is skipped and a teletypewriter message is printed. After 
the completion of the tests, the spc disconnects the CDA circuit from 
the CDT and connects the next one. 

Automatic sequencing of the transmission tests of all CDA circuits 
can be initiated by entering another special code. The spc connects 
each available CDA circuit to the CDT panel, and sequences through 
each of the tests. Once all of the tests for a CDA circuit are complete, 
another CDA circuit is connected. Busy circuits which are skipped are 
identified by teletypewriter messages. 


2.5.3 Vocabulary recital 


Because the announcement decoding aspect of the ssas has no 
existing counterpart in the TSPs, a totally new test feature is provided 
from the cpT panel. This feature is an announcement vocabulary 
recital exercise whereby the maintenance personnel can listen to each 
speech segment in the announcement vocabulary via the cpT telephone 
head set. 

Listening to the announcement output of a CDA circuit provides a 
manual check not only of the CDA circuit announcement decoder, but 
also of the SSAS announcement subsystem circuits. When an announce- 
ment store is loaded from tape, this feature can be used to verify the 
contents of the store before it is made active. The announcement 
recital test can be performed from both active and standby SSAs sides. 
Two options are provided for the recital test. They can be summarized 
as follows: 


(t) The decoding of every announcement segment and phrase in 
sequence. 

(tt) The repetitive decoding of a specified announcement segment 
or phrase. 
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The announcement recital test on an active SSAS side begins with a 
CDA circuit connected to the CDT panel. By operating appropriate keys 
and entering a special test code, the spc starts the PROCON-controlled 
announcement exercise on the active side. This exercise accesses the 
announcement data for a phrase and sends it to the CDA circuit under 
test. It sequences through every word or phrase in the announcement 
vocabulary and then stops. Each word or phrase is separated by % 
second of silence. 

Entering another test code causes a specified announcement phrase 
to be repeated at a constant rate. This is controlled by another PROCON 
exercise which accesses the announcement data for the specified 
phrase and sends it to the CDA circuit under the test. One-half second 
of silence is inserted between repetitions. The phrase is repeated until 
the circuit is released from the cDT panel. 

Similar procedures are used for the announcement recital test from 
a standby ssas side. Again by entering special codes, appropriate 
announcement exercises are started. If the ssas diagnostic is in prog- 
ress on the standby side, the exercise is not run and a teletypewriter 
output message is printed. 
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Traffic Service Position System No. 1: 


Automated Coin Toll Service: 
Human Factors Studies 


By E. A. YOUNGS, W. J. BUSHNELL, and A. BARONE-WING 


(Manuscript received December 28, 1978) 


Automated Coin Toll Service replaces operator handling on most 
toll calls paid for with coins and provides operator handling when 
customers fail to deposit. Human factors work on ACTS consisted of 
first documenting the range and frequency of existing operator inter- 
actions, then simulating various possible versions of machine-pro- 
vided service, and last analyzing simulation results to provide service 
recommendations, performance estimates, and a list of important, 
but unanswered, questions. The simulation also led to the early 
development of operator practice and training materials, evaluation 
tools, and operational requirements, as well as timely discovery of 
potential problems. 


|. INTRODUCTION 


Companion papers describe the hardware and software used to 
provide Automated Coin Toll Service (Acts).'’° This paper describes 
human considerations which contributed to the design and evaluation — 
of the automated service. 

Prior to the development of the hardware and software described in 
the previous papers, many questions were raised: 

(t) Would the automated service be an acceptable substitute for 
Traffic Service Position System (TSPS) operators performing 
routine functions, e.g., deposit request, coin counting, deposit 
prompt, deposit acknowledgment, and others? 

(it) How would customer depositing (and other behaviors) depend 
on service design? 
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(iit) How would customer satisfaction with the service depend on 

the design? 

(tv) How would operators be affected by the automated service? 

These few broad questions implied many specific questions: How 
should performance be measured? What aspects of customer behavior 
are most important? and How should these be measured? 

The human factors work proceeded in three stages: detailed obser- 
vations of existing (operator-assisted) coin toll service to comprehend 
the range and relative frequencies of events; a highly instrumented 
service trial to obtain performance measurements and customer opin- 
ions; and a data analysis and recommendations phase to formulate a 
final service offering, estimate performance, and isolate potential dif- 
ficulties for further study. The remainder of this paper is organized 
around these stages. 

Section II briefly describes early observing studies upon which the 
original service proposal, as well as the provisional announcement and 
timing schemes, were based. Additional confirming observing studies 
are also mentioned. Section III describes the usefulness of service 
simulations—first with operators only, later with computer-driven 
equipment to provide service and measure customer-service perform- 
ance. Section IV describes the technical implementation of the com- 
puterized simulation, Section V describes simulation results and rec- 
ommendations, Section VI estimates performance and acceptance, 
Section VII enumerates unanswered questions, and Section VIII 
briefly mentions some cost-worth factors to be considered in evaluating 
the simulation. 


ll. EARLY HUMAN FACTORS WORK—OBSERVING HOW COIN CALLS 
ARE PRESENTLY HANDLED BY OPERATORS 


At TsPs, toll coin calls are divided into several parts (called position 
seizures) for efficient operator handling. Each seizure accomplishes a 
single function: (z) initial period deposit request and verification of 
complete deposit, (vz) notification at the end of the initial period that 
overtime charges would apply unless the call ended immediately, (viz) 
call interruption, deposit request, and verification after each additional 
10 minutes of overtime conversation, and (iv) ringback (if necessary), 
deposit request, and verification at the end of conversation. The 
human factors effort concentrated on replacing operators performing 
these functions. 

The initial service proposal by J. C. Dalby was based on the 
characteristics of (operator-assisted) station-to-station coin toll calls 
monitored at Neptune, New Jersey and Chicago, Illinois.* Of particular 
interest were: 

(t) The wording of the operators’ deposit requests. 
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(iz) The time from the deposit request until customers deposited 
their first coins. . 

(zit) ‘The number of times operators repeated deposit requests before 

customers started depositing. 

(tv) The times between coins (intercoin intervals). 

(v) How frequently customers began depositing, then stopped and 

asked operators how much was still due. 

C. E. Bronell and M. S. Schoeffler’ conducted a more extensive 
service measurement study in Seattle, Washington, Miami, Florida, 
and Rochelle Park, New Jersey. The objective of this study was to 
reinforce earlier observations and accumulate enough direct observa- 
tions of operator-handled calls to provide a thorough, general descrip- 
tion of the process and of the most common situations likely to be 
difficult for an automated system. Location differences were also 
analyzed. 

From these observational studies, it became apparent that there are 
two general types of coin customers: experienced and (those presumed 
to be) inexperienced. Experienced customers are familiar with coin 
service. They had correct change and often knew the exact charges 
before making the call. After a short initial deposit request (e.g., “50 
cents please”), experienced customers immediately started depositing 
and continued until the requested amount was deposited. If the oper- 
ator used a longer initial deposit request (e.g., “Please deposit 1 dollar 
and 75 cents for the first 3 minutes’), experienced customers often 
began depositing while the operator was still talking. 

At the other extreme, inexperienced customers are not prepared for 
the initial deposit request and often ask for a repetition. They began 
depositing, but occasionally lost count and asked for the remaining 
amount due. Inexperienced customers often did not have the correct 
change and had to deposit too much. The operator informed these 
customers that extra deposits would be credited toward additional 
charges, if any. Some inexperienced customers dialed the call as if they 
wanted to pay with coins when they did not wish to do so and were 
unprepared. (They should have dialed 0 plus the called number.) On 
these calls, the operator adjusted the method of payment. 

As a result of these observations, it was concluded that the sequence 
of announcements and coin deposit intervals should provide experi- 
enced customers with fast efficient service and inexperienced cus- 
tomers with repetitive requests for deposits, prompts for the remaining 
amount due, and automatic transfer of calls to operators when diffi- 
culties were detected. In addition, the automated service should be 
able to acknowledge extra deposits and provide credit toward addi- 
tional conversation time. 

It was estimated that provisional announcements and deposit inter- 
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vals would handle approximately 85 percent of initial deposit seizures 
without operator intervention. On this basis, automated service was 
an economically sound development. However, it was also recognized 
that further refinements in the announcements and timing intervals 
which increased the proportions of mechanized seizures, even by only 
a few percent, would yield substantial additional savings. 


ill. FIRST AUTOMATED SERVICE—SIMULATION BY OPERATORS 


In the spring of 1975, O. O. Gruenz, Jr., conducted an experiment at 
Harrison, New York, Fort Washington, Pennsylvania, and New York 
City, in which the automated service was manually simulated.® Several 
TSPS operators requested deposits and prompted customers using 
proposed announcements and approximate timing intervals. These 
operators were instructed to ignore any questions or comments made 
by customers. 

During the experiment, two variants of the provisional deposit 
request (“Please deposit 35 cents for the first 3 minutes’) were tried to 
reduce customer requests for repetitions of the amounts due: 

(1) “Thirty-five cents please.” (2-second pause) “Please deposit 35 

cents for the first 3 minutes,” 

(it) “Please deposit 35 cents.” (2-second pause) “Thirty-five cents 

for the first 3 minutes.” 

Both these announcements were successful in reducing customer 
needs for additional information. Furthermore, these results indicated 
that mechanized initial deposit seizures could be increased by several 
percent with the proper announcement wordings and timing intervals. 
However, because all record-keeping for this experiment was done 
manually, it was not feasible to explore many options. Thus, the 
experiment did not finally answer any design questions; rather, it 
demonstrated that proper design choices could substantially improve 
system performance. 


3.1 Additional questions about customer/ system performance and 
customer acceptance which justified additional simulation 


In addition to announcement wording and deposit timing, early work 

raised other specific design questions: 

(t) | Would an alerting tone preceding announcements help cus- 
tomers deposit more quickly and/or more reliably? 

(tt) How would customer/system performance and customer ac- 
ceptance be affected by the use of a nasal monotone (“‘ma- 
chine-like’”) voice as opposed to more natural-sounding an- 
nouncements? (There was some speculation that informing 
customers that they were being machine-served would be 
beneficial, and it was thought that voice quality was a reliable, 
non-time-consuming way of doing so.) 
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(tit) Should coin station instruction cards inform customers that 
service is being machine provided? 

Furthermore, a properly designed simulation was expected to: 

(tv) Identify potential overall system weaknesses, overlooked by 
even careful examination of individual system elements and 
stimulate further work where required. 

(v) Give useful experience with microprocessor-controlled, an- 
nouncement-generating equipment and software. 

(vi) Stimulate early development of operator procedures and train- 
ing materials. 

(vii) Aid preparation of an appropriate public relations campaign 
for the introduction of automated service. 

(viii) Provide some engineering information useful in early site 
equipment provisioning. 

(tx) Complement performance measures with customer interviews 
which would reveal preferences and sensitivities to machine- 
provided service. 


IV. COMPUTER SIMULATION OF ACTS 


Various versions of the automated coin toll service were simulated 
using microprocessor-controlled, announcement-generating equip- 
ment. This equipment was originally built by an exploratory develop- 
ment group to demonstrate the feasibility of generating announce- 
ments using digitized segments of speech stored in semiconductor 
memory. However, this equipment lacked much of the hardware and 
software necessary to provide the fully automated service. First, the 
coin detection circuits had not been designed and, second, the circuitry 
and software to interface the microprocessor and the TSPs processors 
had not been developed. Thus, to simulate the automated service, it 
was necessary to have TSPs operators relay call and coin deposit 
information to the microprocessor. A minicomputer and a TTY were 
used as interface between the operator and the microprocessor. In 
addition, the minicomputer provided all the necessary timing intervals 
and a record of the call events on a 9-track tape (see Fig. 1). 

The sequence of events on a simulated ACTS call were as follows: 

(t) The call seized a position and the initial period length and 

charges were displayed to an operator. 

(tz) The operator transmitted the information to the minicomputer 
via the TTY. 

(zit) The minicomputer sent instructions to generate an announce- 
ment (deposit request) which was patched into the customer- 
operator voice path. 

(tv) As the customer deposited coins, the operator depressed keys 
on the Try which were interpreted by the minicomputer as 
nickels, dimes, or quarters. 
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The timing and initiation of the announcements were under mini- 
computer control, as were instructions to the operators. If the customer 
did not deposit coins, a second operator (sometimes with no previous 
knowledge of the call) assisted the customer, providing a customer- 
operator situation much like the eventual service. 

Two operator positions (each with two operators) were equipped 
with Trys. To ensure that these positions received only station paid 
coin calls, a special set of program overwrites was installed in the TsPs. 
In addition, other overwrites were inserted to ensure that calls at the 
special positions originated from one of a selected set of coin stations. 
Coin stations were selected to facilitate interviewing, traffic manage- 
ment, station instruction card study, and traffic sampling. 


4.1 Administration of the simulation— hourly traffic distribution 


Figure 2 illustrates the hourly distribution of simulation traffic and 
the corresponding distribution for coin-paid toll traffic at Illinois Bell’s 
Great Lakes tsps. This representative sampling for weekdays was 
attained by choosing an appropriate mix of 8-hour shifts over the three 
months of study. The simulation was operated for one shift per 
weekday, as well as a few weekends. 


4.2 Station selection and activation 


Stations participating in the trial were those most frequently used 
for coin-paid toll calls in the host Tsps serving area. A total of 732 
stations were activated at various times. However, at busy times during 
the day, fewer than 100 generally received simulated service. The 
number of active stations was adjusted dynamically to keep (one or) 
two trial positions as busy as possible, without overflowing calls to the 
regular team more than 10 to 15 percent of the time, on the average. 


4.3 Varying elements of the service design 


To answer the service design questions at hand, a daily schedule of 
service variants was constructed to sometimes include an alerting 
tone/no tone, a “machine-like’/natural announcement voice, etc. 
Overall service was composed of variable elements in a way that 
allowed the effects of each element to be partialed out by appropriate 
analyses. Ongoing analyses quickly suggested that some service ele- 
ments be eliminated from further consideration and that others be 
tried. 


V. CUSTOMER/SYSTEM PERFORMANCE—ANALYSES, RESULTS, AND 
DESIGN RECOMMENDATIONS 


Table I presents some key results derived from simulating over 
seventeen thousand automated initial deposit seizures. The table 
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Fig. 2—Approximate business day and simulation study sampling distributions. 


shows regression estimates of the effects of design decisions on impor- 
tant service performance measures. Mechanization rate is the percent- 
age of calls handled without operator assistance. Walkaway rate is the 
percentage of calls going into overtime but not fully paid for by 
customers “walking away.” Abandonment rate is the percentage of 
calls that customers abandoned prior to receiving busy or ringing 
signals. 

The body of the table contains estimates, as percentages, of the 
incremental effects of several important service components. For ex- 
ample, the alerting tone is estimated to decrease mechanization rate 
by 0.2 percent, to increase walkaway rate by 1.4 percent, and to have 
no measurable effect on abandonments. Service component effect 
estimates are arbitrarily constrained to a zero sum on each perform- 
ance measure. 
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Table |—Estimates of design decision effects on initial deposit 
request handling performance measures 
(J indicates decisions taken) 


Estimated Performance Measure Increments 





Mechanization Walkaway Abandonment 


Service Components Rate (%) Rate (%) Rate (%) 
Alerting Tone (T) 

Present (Tone) —0.2 +1.4 Nil 
J Absent (No Tone) +0.2 —1.4 Nil 
Voice Quality (V) 

Machine (Mach) -0.1 +18 +0.2 
J Natural (Nat) +0.1 —1.8 —0.2 
Announcement Wording 

“Please deposit $X.XX for...” —2.2* +4.7 +0.1 
J “$X.XX please. Please de- +1.3* -1.7 —0.8 

posit...” 

“Please deposit $X.XX, $X.XX +0.9* —3.0 +0.7 

for...” 
Deposit Interval Allowed 

4.5 secs —3,7* -1.6 —0.9 
V 6.0 secs} +1.3* +1.5 —0.3 

8.0 secs +2.4* +0.1 +1.2 
Speech Detector (S) 

Present (Det) —1.0 +0.9 -0.1 
Vv Absent (No det) +1.0 -0.9 +0.1 
Interactions 

Tone/ Voice 

Tone-mach or No tone-nat +0.7 +0.5 +0.3 

Tone-nat or No tone-mach —0.7 —0.5 —0.3 
Voice/Speech Detector 

JV Mach-det or Nat—no det +0.3 —1.5 —0.2 

Mach—no det or Nat—det —0.3 +1.5 +0.2 

Constants 86.4 19.8 11.5 


* (Column) contrasts statistically different (p < 0.01). 
+ 5.5 secs selected, but 6.0 secs estimates used. 


Most individual effects are estimated to be small—too small to be 
considered statistically different from zero with confidence. Those 
large enough to reach statistical significance at the 99-percent confi- 
dence level are indicated with asterisks. However, estimated effects 
are additive, in general. 

The lower section of the table, labeled “Interactions,” presents the 
estimable two-component interactions. These are, in effect, adjust- 
ments to the additive estimates above them. Because of the experi- 
mental design, not all such adjustments can be estimated. 

To compare the performance of designs, sum estimates correspond- 
ing to each service design. For example, the service utilizing tone, 
natural voice, operators’ announcement wording (shown first in the 
table), a 4.5-s deposit interval, and no speech detector would be 
expected to have a 10.3-percent lower mechanization rate than the 
service indicated by the checks (J). By adding the constants given in 
the bottom row of the table, the actual estimated rates are obtained. 
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Thus, the checked components result in estimates of 91.3, 14.5, and 
10.4 percent for mechanization, walkaway, and abandonment rates, 
respectively, whereas the example alternative service results in esti- 
mates of 81.0, 19.6, and 10.1 percent, respectively—slightly better 
abandonment performance at the expense of mechanization and 
walkaway rates. 


5.1 Alerting tone effects and recommendations 


Prior to the simulation, it was reasoned that a short alerting tone 
would better prepare customers to understand the announcement 
requesting deposit and/or better prepare them to deposit promptly in 
cases when they knew the amount from previous experience. Thus, 
use of the tone should result in shorter times to first coin and better 
overall performance. 

In addition to the effects presented in Table I, our data indicated 
that the 4-s alerting tone we used had no significant effect on time to 
first coin in most situations. However, on intermediate overtime re- 
quest seizures, the tone boosted the seizure mechanization rate signifi- 
cantly: the tone, apparently, interrupts conversation more effectively 
than the announcement alone. Thus, the alerting tone is being used 
only on intermediate deposit seizures. 


5.2 Voice quality 


As mentioned earlier, a machine-like voice quality was tested in the 
simulation. It was thought customers might be able to respond more 
effectively to deposit requests if they realized they were being machine- 
served and they did not try to converse with the system. 

The system performance effects of the machine-like voice were 
small, mixed, and generally not of practical importance; though 
walkaway rates are, apparently, increased. Overall, trends favored a 
natural voice slightly. However, interviewed customers strongly pre- 
ferred the natural voice. Consequently, natural voice announcements 
are incorporated in the system. 


5.3 Announcement wordings 


Fairly early in the simulation study, the operator deposit request 
phrase (typically), “Please deposit 25 cents for the first 3 minutes,” 
(listed first in Table I), was found to be less effective for the automated 
service than others. Repetition of the amount decreased average time 
to first coin and walkaway rate while increasing average proportion of 
seizures automated. 

In retrospect, the improved performance associated with repeating 
the amount due is not surprising since Bronell and Schoeffler found 
that operators repeat deposit requests 3 to 15 percent of the time. 
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Because the automated service would not be able to respond directly 
to customer repeat requests, improvement is achieved by repeating 
amounts to everyone who does not deposit immediately. 

The request wording chosen for ACTs is “25 cents please.” (2-second 
pause) “Please deposit 25 cents for the first 3 minutes.” Most customers 
begin depositing during the pause, truncating the announcement se- 
quence. 


5.4 Deposit and announcement intervals 


The primary tradeoff for deposit timing is between allowing short 
intervals that favor customers who deposit quickly (but occasionally 
need the amount repeated) or need an operator,* and long intervals 
that avoid attaching an operator needlessly for customers who deposit 
slowly. 

Announcements that repeat the deposit amount reduce the need for 
whole announcement repetition. Thus they increase the overall desir- 
ability of long interannouncement intervals, i.e., fewer customers must 
wait for prompting announcements. However, for customers needing 
an operator, lengthening interannouncement intervals degrades service 
quality. Therefore, in the final AcTs environments where relatively few 
customers reach AcTs when they need an operator, relatively longer 
intervals are desirable; in the environment where more who reach ACTS 
need an operator, shorter intervals are desirable. The appendix con- 
tains a discussion of a potential means of discriminating between 
customers who need operators and those who do not. 

For initial deposit request seizures, 5.5-s interannouncement inter- 
vals were incorporated into the system. This choice represents an 
attempt to balance the mechanization rate benefit of 6.0 s and the 
walkaway reduction of 4.5 s (see Table I). For intermediate and end- 
of-conversation seizures, an 11-s interval is followed by operator at- 
tachment because repetition of the whole announcement was found to 
be ineffective in obtaining additional deposits. 


5.5 Instruction cards 


Bright orange instruction cards were placed on half the simulation 
coin stations, chosen randomly. Previous studies had indicated that 
coin station instruction cards are rarely noticed or used by customers. 
It was reasoned that, if such an attention-getting color was ineffective, 
no less noticeable card would work. © 

As anticipated, no practical, consistent changes in customer/system 
performance resulted from the use of bright orange cards. Customers 


* Incorrectly dialing a “1” instead of “0” prefix will result in reaching acts instead of 
an operator. This dialing error is quite common now in areas where “1” is used to specify 
a station toll call to be paid by coin deposit. 
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did use stations with orange cards about 6 percent more often on the 
average, indicating that they noticed the cards from a distance. How- 
ever, when interviewed about service, immediately after using stations 
with these cards, customers very rarely remembered any card details, 
including the color or the statement, “Note: Charges may be requested 
by a recorded announcement during an equipment trial.” Therefore, 
no special card design or card information was recommended. 


VI. CUSTOMER/SYSTEM PERFORMANCE AND CUSTOMER 
ACCEPTANCE ESTIMATES FROM SIMULATION RESULTS 

Simulation results are not only useful in reaching design decisions 
but also in estimating customer/system performance for the design 
chosen. However, these estimates are strictly applicable only to the 
simulation site. Because the Bronell and Schoeffler service measure- 
ment study indicated that sites bear many overall similarities as well 
as significant differences, many findings of the simulation are expected 
to be accurate more generally. (Field performance of the final ACTs in 
the simulation site will provide valuable information about the ade- 
quacy of the simulation.) 


6.1 Times to first coin 


Fifty percent of first coins were obtained within 6 seconds of the 
beginning of the first announcement. Ninety percent of first coins were 
obtained in 12 seconds, 95 percent in 14 seconds. 


6.2 Proportions of seizures mechanized 


Seizure mechanization rates are estimated at 91 percent for initial 
deposit seizures, 64 percent for intermediate deposit seizures, and 76 
percent for end-of-conversation deposit seizures. Notification (at the 
end of the initial period) seizures, because they require no deposit, will 
be essentially 100 percent automated. Overall, these rates are expected 
to rise with customer experience, but the rate of increase cannot be 
predicted from simulation data, since it was conducted over a relatively 
short (3-month) period with intermittent service at a limited number 
of stations. 


6.3 Abandoned call attempts 


Abandoned call attempts, which can occur only on initial deposit 
seizures, are estimated to be about 10 percent of initial deposit seizures. 
This rate is expected to decline as customers become accustomed to 
service. Abandonment from the stations used in the trial, on calls 
handled normally by operators, was about 7 percent. 


6.4 Walkaway rate 


The walkaway rate for the design chosen is estimated initially to be 
about 14.5 percent of calls extending beyond the initial period. How- 
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ever, the validity of this estimate is difficult to assess. It is considerably 
higher than the 7 percent for operator-handled calls from the same 
stations over the trial period. Furthermore, even though no trends 
were detected during the trial, the walkaway rate is not expected to 
decrease with customer experience. 

Walkaway rate is being carefully monitored in the first AcTs instal- 
lations to determine the need to adopt alternative overtime collection 
strategies. 


6.5 Customer acceptance of automated service 


Interviewed simulation customers generally preferred operator ser- 
vice to automated service. More than a third expressed very strong 
preference for operator service (8 or 9 on a 9-point scale from 1 = 
“strongly prefer automated service” to 9 = “strongly prefer operator 
service”). About 15 percent preferred automated service. 

The quality of announcements was the most often noticed clue to 
customers that they were being machine-served. Seventy-one percent 
of the interviewed customers receiving the natural voice announce- 
ments recognized machine handling; 79 percent recognized the ma- 
chine-like voice. However, it should be noted that 28 percent of the 
interviewed customers who received operator service thought their 
calls had been automated. 

Overall, interview data indicate that customers will prefer operators 
to ACTS initially. As they gain experience with ACTS, acceptance: is 
expected to grow due to increasing familiarity. 


Vil. QUESTIONS UNRESOLVED BY THE SIMULATION TRIAL 


Several important questions were not answered by the simulation 

study. They will be studied in early Acts sites: 

(z) Will long-term customer acceptance require modification of the 
service? 

(tt) How will the operator task be affected by acts? (Customers 
reaching operators will often be those who have failed to satisfy 
ACTS.) 

(tit) Will walkaway rates remain at tolerable levels? 

(tv) Should acts employ different announcements, timings, etc., in 
different locations? In the same location over time? 

(v) Should a voice detector be incorporated into Acts? (See the 
appendix for discussion of the voice detector.) 


Vill. COST/WORTH ANALYSIS OF SIMULATION AND OTHER HUMAN 
FACTORS STUDIES 


In addition to the savings provided by the initial proposal for ACTs, 
improvements in the ACTS seizure mechanization rate due to human 
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factors work will yield substantial additional savings. Operator proce- 
dures and associated training materials developed for the simulation 
study were valuable in preparing for the actual service. Customer/ 
system performance and customer acceptance evaluation tools pre- 
pared for the trial are now being used to evaluate early ACTS installa- 
tions. 

In addition, the simulation experiment forced the development, 
systems engineering, and AT&T operator services organizations to 
understand the new service in depth early in the development cycle. 
This understanding permitted early formulation of very detailed op- 
erational requirements. The experiment also provided an early indi- 
cation of some unanticipated development problems. For example, it 
was discovered that the editing features for analog announcement 
source tapes were not adequate for producing high-quality announce- — 
ments. A digital phrase-editing system was consequently proposed and 
developed in time for the first installation. 
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APPENDIX 


Considerations Leading to Proposal and Evaluation of a Voice Detector 
to Discriminate Between Customers Who Need an Operator and Those 
Who Do Not 


Manual simulations revealed a problem inherent in the scheme of 
using machine-controlled announcements to obtain customer deposits: 
a long interannouncement interval is desirable to allow the slowest 
customers to make deposits without being “rushed,” but a short 
interannouncement interval gives better service to customers who 
need immediate repetition of the announcement or operator assistance. 
What is needed is a way to discriminate between the two situations. 

A potential solution was suggested during the manual simulations 
when we observed that customers desiring operator assistance often 
ask questions or make statements during the intervals following an- 
nouncements, whereas customers preparing to deposit generally do 
not. For example, customers who say things like, “How much was that, 
operator?” “Make that a credit card call, operator,” or “This is a 
collect call,” need either an announcement repetition or an operator. 

A “voice detector” was devised and built to end the ongoing deposit 
interval if speech occurs. Initially, this causes the announcement to be 
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repeated. If talking persists, an operator is more quickly attached. 
Intuitively, this makes possible the provision of long intervals for 
(silent) customers slow to deposit while responding more promptly to 
those (speaking) who need announcement repetition or operator as- 
sistance. 

The simulation trial did not provide a sensitive test of the voice 
detector for several reasons: 

(t) Potential benefit is limited a priori to those users who need 
announcement repetition or an operator. The need for an- 
nouncement repetition was largely eliminated by selecting an- 
nouncements that state the amount twice. Also, customers 
needing an operator due to dialing errors (“one plus” instead of 
“zero plus”) were unusually rare in Chicago compared to other 
cities Bronell and Schoeffler characterized. 

(tt) No sensitive measures of the service improvements afforded by 
the voice detector were readily available. (Customers are una- 
ware of the voice detector, and we were able to obtain very 
limited observer data.) 

Our limited data indicate that the voice detector operated as in- 
tended. It was triggered in about 56 percent of the cases for which a 
shortening of the interval was beneficial but acted only 6 percent of 
the time when it was not potentially beneficial. The majority of cases 
it missed were due to customers talking during an announcement 
(when it was disabled because it would have been triggered by the 
announcement—an easily rectifiable design flaw). However, the voice 
detector had only a minor impact on primary performance criteria. 

Inclusion of the voice detector cannot be recommended on the basis 
of the data available from the simulation. However, the problem the 
voice detector was devised to solve still exists and could, at some future 
time, be shown to justify voice detector inclusion in ACTS or other 
mechanized services where customer speech is a reliable and useful 
indicator. 
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This paper is concerned with the development tools, strategies, and 
methodologies employed by Traffic Service Position System (TsPs) 
application programmers for the creation and testing of TSPSs soft- 
ware. Two environments are described: (i) The support environment 
provided by an IBM 370/168 and related TsPs support software 
packages for the production of testable Tsps software. (ii) The support 
environment provided by the Tsps system laboratory, utility system, 
and specialized hardware for testing the Tsps software. 


I. INTRODUCTION 


This paper describes the tools of Tsps software generation and 
testing in the following environments: 
(t) The facilities provided via a general-purpose IBM processor for 
the production of testable TSPS software. 
(ut) The facilities provided by the TsPs system laboratory for testing 
new and changed TspPs software in an operational environment. 
Section II is concerned with the IBM support environment utilized 
by TSPs application programmers. The major tools and strategies are 
described. More important, the methodologies that make use of these 
tools are explained. Section III is concerned with the testing environ- 
ment provided by the Tsps system laboratory. This environment 
combines an actual TsPps machine, a utility system and related software, 
and special hardware for debugging TsPs software. 


ll. SOURCE CODE DEVELOPMENT AND GENERATION OF SPC- 
LOADABLE OBJECT CODE 


This section concerns itself with the general environment of TSPs 
source code creation, modification, and preparation for testing using 
the Tsps system laboratory and associated utility systems. 
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2.1 General software support environment of TSPS 


The software required to operate a particular TsPs installation is 
comprised of approximately 300 programs (PIDENTs) totaling over 200 
thousand 40-bit Stored Program Control (spc) 1A machine instruc- 
tions. The combination of these 300 PIDENTs into an issuable (via 
Western Electric) software package is referred to as a generic release. 
There are currently four active TSPs generic releases, each having 
implemented a major new Tsps feature. 

The implementation of new minor enhancements are normally pro- 
vided by a new release of an existing active generic. All capabilities 
provided by the software of a lower numbered generic are also provided 
by the higher numbered generic in addition to the new major feature. 
The starting point for software development of a new generic will be 
the current state of the source modules comprising the previous 
generic. Many of these modules remain unchanged in the new generic. 
Others are modified to produce a new version of the PIDENT that adds 
the new capabilities for the new generic. In addition, new PIDENTs are 
created for the new generic. It is therefore possible to have to maintain 
as many versions of a PIDENT as there are active generics. 


2.1.1 Featuring and a single source environment 


Four active generics with 300 PIDENTs per generic could imply that 
1200 PIDENT source modules would have to be maintained. This is not 
the case. TSPS employs the use of “featuring” to maintain a single 
source module for a PIDENT regardless of the number of distinct 
versions of that PIDENT. Featuring basically means the following: 


Any addition to a PIDENT source module must be bracketed by 
feature control directives which, during the assembly of the source 
module, direct the assembler to either assemble or ignore the 
bracketed source code. Any existing source lines to be replaced/ 
deleted are likewise bracketed. 


This implies that a single source for a PIDENT can be maintained 
which is capable of generating multiple versions of the PIDENT’s object 
module (i.e., the output of the assembler). By appropriate feature 
control directives to the assembler, different versions of a PIDENT can 
be assembled. In speaking of multiple versions of a PIDENT due to four 
active generics, what actually is meant is that multiple versions of a 
PIDENT’s object module are producible from a single PIDENT source 
module. 

The feature control directives employed by TSPs are: 


INFOR feature expression 
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OUTFOR feature expression 
ENDFOR feature expression. 


The term “feature expression” in all three is a Boolean expression 
which is evaluated as “true” or “false” by the assembler. INFOR implies 
“assemble” the following source lines if the feature expression is true. 
OUTFOR implies “ignore” the following source lines if the feature 
expression is true. ENDFOR Is the terminating bracket for source lines 
to be assembled/ignored. INFOR with a true feature expression is the 
same aS OUTFOR with a false feature expression. “Feature expressions” 
may be combined with Boolean “and,” “or,” and “not” operations. 

Each generic has associated with it sets of feature expressions that 
always evaluate as true. Every assembly of a PIDENT source module is 
initiated by the processing of a special control statement which speci- 
fies the generic for which the PIDENT is being assembled and therefore 
the feature expressions which are to be “true” for this particular 
assembly. 


2.1.2 Software development support environment 


Software to be executed on the Tsps spc 1A is generated by means 
of the computing facilities of an IBM processor located at the Colum- 
bus, Ohio branch laboratory of Bell Laboratories. This facility operates 
the OS/370 operating system with the IBM Time Sharing Option 
(tso). The latter point is significant because the Tsps development 
organization resides at the Indian Hill laboratory in Naperville, Illinois. 
All accesses to the TSPs software data base are through TSO via dial- 
up terminal access from Indian Hill. The high-speed data network 
(VIPERDAE) connecting Columbus and Indian Hill allows hard copy 
and tape output to be returned to Indian Hill. 

TSO provides the needed interactive facilities to both TsPs application 
programmers and TSPsS program administration personnel for data base 
administration, PIDENT creation and modification, and submission of 
OS/370 batch jobs for assemblies, loads, etc. It should be mentioned 
that this interactive environment was new for TSPS with the develop- 
ment of Generic 8. Before Generic 8, the software development envi- 
ronment was punched-card-oriented, with all functions to be per- 
formed being initiated via over-the-counter submission of card decks. 

2.1.2.1 Creation and modification of PIDENT source modules. 
The major Tso-provided tool utilized by Tsps application programmers 
for the creation or modification of PIDENT source is the QED text editor. 
QED is a powerful, flexible, and general-purpose text editing facility 
capable of either line number or context editing on a range of various 
OS/370 file organization types. It should be mentioned at this time 
that TsPps application programmers do not directly modify existing 


SOFTWARE DEVELOPMENT TOOLS- 1309 


PIDENT source modules. Since a single-source module is used to gen- 
erate (via assembly) the object modules for more than one active 
generic, it is felt that direct modification of the PIDENT source for any 
particular generic is too dangerous. Instead, TsPs employs the use of 
two editors for PIDENT source modification. Via QED, the application 
programmer is actually creating the editor statements to be processed 
by the Advanced Processor Editor (APE). APE is a very simple, line- 
number-oriented editor. It provides only the basic “insert,” “replace,” 
and “modify” functions and is specifically designed to operate in 
conjunction with the TsPs assembler. In almost all cases, APE and the 
TSPS assembler are executed in sequence in the batch environment of 
the OS/370. APE applies the edits created via QED to the official PIDENT 
source and outputs a temporary edited copy of the PIDENT source, 
which is then assembled. The actual PIDENT source module is not 
altered during this sequence, although the mechanism does exist in 
APE to permanently apply the edits to the PIDENT source module, 
renumber all lines sequentially, and regenerate the PIDENT source 
module. From this point on, any reference to a PIDENT source module 
is actually a reference to a PIDENT source module in combination with 
the official module of APE edits for that PIDENT. 

2.1.2.2 The TSPS assembler. The creation/modification of TSPs 
PIDENT source (source + APE edits) is only the first step in a sequence. 
This sequence of functions will eventually produce an output from the 
IBM support machine which is capable of being executed and tested 
on the Tsps system. 

The second step in this sequence is the conversion of the PIDENT 
source module into an assembled object module suitable for input to 
the load step. This conversion process combines the execution of the 
APE editor to produce a temporary modified source module, followed 
by the assembly of this modified source module by the spc-SwAP 
(Switching Assembly Program) assembler. Primary outputs of the spc- 
SWAP assembler are an object module and an assembly listing corre- 
sponding to a particular version of the PIDENT. SPC-SWAP is an excel- 
lent, high-powered assembler which possesses an assortment of 
pseudo-operations for controlling listing format, symbol definitions, 
etc. SPC-SWAP also includes powerful MACRO definition and usage 
facilities. 

Another facility of the spc-swaP assembler which is heavily used by 
TSPS in its multigeneric environment is the capability to create a 
special file (referred to as a library) of symbol or macro definitions 
which can then be accessed by subsequent PIDENT assemblies for the 
purpose of symbol or macro resolution. It is the library and macro 
facilities of SPC-SWAP which allow the single-source, multiple-generic 
environment of Tsps to be viable. The feature control directives 
described in Section 2.1.1 are actually macros available through the 
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library facility to each TSPS PIDENT assembly. The control statement 
which initiates each PIDENT assembly is again a macro (the PACKAGE 
macro). Execution of the PACKAGE macro, which basically takes a 
generic name as a parameter, establishes the generic environment of 
the assembly (i.e., what feature expressions evaluate as “true”; what 
generic-dependent libraries of symbol, macro, and data definitions will 
be available during the assembly; what “name” should be given to the 
produced object module; etc.). Simply by “inserting” via APE a different 
specification for the PACKAGE macro and reassembling, a single-source 
module is capable of producing many different generic-dependent 
versions of its object module. 

2.1.2.3 The TSPS loading process. Object modules produced by 
the SPC-SWAP assembler are not suitable as input to the Tsps. The final 
step in the sequence of operations which produces sPpc-compatible 
output is the execution of the spc loader on the IBM support machine. 
Primary inputs to the spc loader are the object modules for all PIDENTs 
comprising a particular generic software release and control directives 
specifying such things as (i) what areas of SPC memory are available 
for loading PIDENTs, (it) what PIDENTs are to be loaded and, if neces- 
sary, at what addresses, and (zit) what types of maps and cross 
references are to be generated. In these respects, the spc loader is very 
similar to most relocatable linking loaders. Primary output of the spc 
loader is an 800-bits-per-inch, 9-track tape representing the relocated, 
fully linked generic load module which is capable of being read into 
SPC memory and executed. Corresponding to the tape output is a 
printed load map showing memory assignments, available space, etc., 
and optionally cross-reference listings showing entry point definition 
and PIDENTs referencing. 

An additional capability of the spc loader is somewhat unique to 
ESS-type loaders and is heavily used during TsPs software development. 
When creating a full generic software load of all 300 or so PIDENTs, the 
spc loader can be directed to create a special file, called a HISTORY, 
into which detailed information concerning the generated load is 
written. The information includes the names of all PIDENTs loaded; 
the addresses at which they were loaded; how much space each 
consumed; what entry points each defined; where each entry point was 
referenced; where and how much free SPC memory remains; what SPC 
memory was originally available to be loaded; and a complete copy of 
the relocated, linked, and loaded sPc memory. On a subsequent exe- 
cution of the spc loader, the HIsToRy file can be reinput to provide the 
capability for what is known as a partial load. On a partial load, the 
spc loader need only be informed of changes to be made to the previous 
full load represented by the HISTORY. Previously loaded PIDENTs can 
be unloaded or replaced by new versions, new PIDENTs can be added, 
additional SPc memory can be made available for loading into, and a 
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new HISTORY reflecting all changes can be generated. Of particular 
importance is that, on a partial load, the tape that is generated reflects 
only the difference between the updated load image and the previous 
load image that had been saved on the input HISToRY file. This partial 
load facility of the spc loader provides spc application programmers 
with an incremental load capability that is the basis for one of TSPS’s 
primary software development methodologies to be described. 

2.1.2.4 The Interactive Program Administration System. IPAS 
(Interactive Program Administration System) is a tool developed for 
use by TSps and other spc 1A based systems. IPAS executes in the 
interactive TSO environment and primarily serves to shield the appli- 
cation programmers and program administration personnel from the 
complexities of the OS/370 operating system, specifically the nontrivial 
Job Control Language (JCL) required for batch execution of spc-related 
support tools. IPAS is based on the concept of PIDENTs and versions of 
PIDENTs and utilizes the Bell Laboratories Data Management System 
(DMS), a hierarchical data base system. IPAS provides the TSPS user 
with access to QED for line edit file creation and a simple command 
language for initiating the execution of the SPC-swaAP assembler, the 
spc loader, and other minor support tools. IPAS was developed for use 
with all Tsps generics but to date has been most extensively used on 
the Generic 8 development. 


2.2 TSPS software generation methodologies 


The discussion to this point has centered on the support tools and 
basic implementation strategies available for generating and preparing 
for execution the TSPS PIDENT source modules. The discussion now 
turns to the methodologies which make use of these tools and strate- 
gies. Two methodologies will be covered, one which applies to software 
generation in a relatively free administrative atmosphere, and another 
which applies to software generation in a very tightly controlled change 
environment. Both have been applicable to the recent Generic 8 
development, and in fact both were formulated for the Generic 8 
development. Both are equally applicable to the other generics. The 
two methodologies correspond to the two administrative modes under 
which TsPs application programmers work. The “development” mode 
implies the free atmosphere; the “frozen” mode, the tightly controlled 
atmosphere. 


2.2.1 Development mode methodology 


The “development” mode primarily applies to the generation of a 
major new feature, and therefore to a new generic. In this mode, the 
object is to provide the application programmers with as much freedom 
as possible in generating the new feature. For this reason, there is little 
restriction on how the programmers modify existing PIDENTs or create 
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new PIDENTs. The methodology formulated for this “development” 
environment is heavily based on the team programming concept and 
the partial load capabilities of the spc loader. 

The overall software development of the Automated Coin Toll 
Service (Acts) feature was divided basically along functional lines. 
TSPS application programmers were organized in programming teams 
based on these functions. The implementation of a given function 
required the modification of some subset of the 300 or so TSPS PIDENTS 
and the creation of new PIDENTs. The functional subsets of PIDENTS 
were not necessarily mutually exclusive. Many times multiple functions 
required modification to the same PIDENT. The startup point for the 
software development of Generic 8 was the stable state of the Tsps 
software as it existed for Generic 7 in the second quarter of 1976. TSPsS 
program administration personnel set up the proper PACKAGE macro 
for Generic 8 and established the Generic 8 dependent macro and 
symbol libraries which the PACKAGE macro would make available to 
the SPC-SWAP assembler when performing Generic 8 assemblies. All 
Generic 7 PIDENTs were then reassembled to produce relocatable 
Generic 8 versions of the PIDENT object modules. Recall that a PIDENT 
source is actually the combination of the official (i.e., Program Admin- 
istration Group [PAG] controlled) PIDENT source module and the 
official file of APE line edits for that PIDENT. All relocatable Generic 8 
object modules were then input to the spc loader to produce a full 
Generic 8 load module. This load module was designated the “Base 0” 
Generic 8 load, capability-wise identical to the Generic 7 state from 
which it was generated, and loadable and executable in the TsPs system 
laboratory. The foundation upon which to build Generic 8 was estab- 
lished. 

The programming teams were now capable of incrementally modify- 
ing this “Base 0” load and testing their function implementation. To 
illustrate the methodology, assume programming teams 1 and 2. The 
function of team 1 requires modification of PIDENTs A, B, and C, and 
the creation of a new PIDENT D. The function of team 2 requires 
modification of PIDENTs A, E, F, and G. Team 1 would proceed as 
follows: 

(t) Exact copies of the official line edit files for PIDENTs A, B, and 
C would be created using QED. Each would be modified as 
needed for team 1 function implementation. 

(tt) The source for new PIDENT D is created using QED. 

(tii) An SPC-SWAP assembly is initiated via IPAS or other Tso facili- 
ties utilizing the copied and modified team 1 line edit files for 
PIDENTs A, B, and C and the created source file for PIDENT D. 
The object modules produced by spc-swaP are saved as team 
1 object modules. 

(tv) Using the spc loader, initiated via IPAS, a partial load is gen- 
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erated based on the HISTORY file corresponding to the ‘“‘Base 0” 
Generic 8 load. PIDENTs A, B, and C are replaced by team 1 
versions, and PIDENT D is added. The partial load tape pro- 
duced reflects only the differences between the team 1 load and 
the “Base 0” load. 

(v) Team 1 is now capable of overlaying their partial load image 
on top of a known-to-be-stable “Base 0” load image in the Tsps 
system laboratory and testing their function unencumbered by 
new code from other teams. 

(vi) The cycle can be reiterated as problems are discovered during 
testing, except that modifications are made to team I line edit 
files. 

Team 2 has concurrently been developing their function following 
the same procedures as outlined for team 1. This approach allows very 
extensive testing of individual functions, comprising large amounts of 
new and modified software, to be accomplished prior to a large-scale 
integration of functions. 

The PAG personnel again became involved with the Generic 8 
development at periodic intervals (usually 6 to 8 weeks) to produce an 
updated base load. In preparation for performing the official reassem- 
blies for all PIDENTs modified by the programming teams, a merging of 
official and team line edit files must take place. 

Recalling that both teams 1 and 2 copied the official line edit file for 
PIDENT A, the PAG personnel would first merge the team line edit files 
for PIDENT A, and the result would then be merged with the official 
line edit file for PIDENT A to produce an updated official line edit file. 
PIDENTs modified by a single team required only a single merge. The 
final merge with the official line edit file guaranteed that no original 
official line edits had been inadvertently deleted or modified in such a 
way as to adversely affect generics. Having completed the merging 
process, PAG could then make any required modifications to Generic 8 
macro or symbol libraries, and then reassemble all modified PIDENTs 
to produce updated official Generic 8 object modules. These object 
modules now would contain all the function code tested by the indi- 
vidual teams up to the time the new base was created. PAG then 
reexecutes the spc loader to produce a “base n + 1” load module and 
corresponding HISTORY file. The base load image in the TsPs system 
laboratory is then updated to “base n + 1,” and the new base can be 
system-tested to ensure stability. 

Although a large amount of new and modified software is introduced 
with a new base load, the interval between the start of the merging 
process and the completion of the system testing of a new base 
averages about 2 weeks. During this interval, the programming teams 
are able to continue working against “base n,” with the stipulation 
that any additional team line-edit changes must be incorporated with 
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the updated official line-edit files reflecting “base n + 1.” Due to heavy 
testing of individual team functions, a minimum amount of system 
testing is required to stabilize the new base load, even though the 
functions had not previously been integrated. 

Prior to Generic 8, the “development” mode methodology was based 
on manually overwriting a load image in the Tsps system laboratory to 
test new functions or including untested software in new load images. 
System testing of new load images was an enormous, time-consuming 
task. Function testing via manual overwrites was more of a hindrance 
to software development than a help. 


2.2.2 Frozen mode methodology 


The “frozen” mode of software generation applies primarily to active 
generics which have been issued through the Western Electric Com- 
pany, and to the latter stages of the development of a new generic. 
The objective of the “frozen” mode is to maintain the maximum 
amount of stability in the generic software by providing a highly 
controlled and documented change environment through which appli- 
cation programmers must make software corrections. 

For a generic in the “frozen” mode, software change is initiated in 
response to a written Trouble Report (TR) documenting a suspected 
problem or a needed improvement. The “frozen” mode imposes a 
number of restrictions on the application programmers and PAG as to 
the manner of software change: 

(t) No change to a PIDENT can cause the size of the PIDENT’s object 
module to either increase or decrease. 

(ti) The primary method for testing is not the partial load, but 
incrementally applied changes to the frozen generic’s load 
image in the Tsps system laboratory. 

(ziz) Line edit changes corresponding to a laboratory change must 
produce a bit-for-bit match between the PAG-generated (via 
PIDENT reassembly) next release of the frozen generic and the 
overwritten old release in the TSPS system laboratory. 

(tv) All programmer-generated changes must be independently 

tested and approved by a generic test team. 

The application programmer must generate a written Correc- 
tion Report (cR) documenting any changes made in response 
to a TR. 

(vi) Not only must the change be independently tested, but the TR, 
CR, overwrite, and line edits must be approved by a generic 
software change review committee prior to the line edits being 
included in the next release of the frozen generic. . 

To alleviate some of the problems associated with (z), (iz), and (zzz), 
above, a functionally identical set of “patching” directives exists, 
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available to both the spc-swaPp assembler and the test laboratory 
utility system overwrite assembler. In the case of spc-SwapP, these are 
TSPS system macros available to any PIDENT assembly. They are 
merely control directives to the utility system overwrite assembler. 
These “patching” directives allow the application programmers to add 
new software, replace existing software, or delete existing software 
within a PIDENT without altering the assembled size of the PIDENT. 

Primary input to utility system overwrite assembler is a deck of 
punched cards, composed of symbolic sPc source to be assembled, and 
utility system control directives. A few major restrictions on the change 
to be assembled are: 

(t) There is no macro capability. Any macro to be assembled must 
be manually expanded prior to input. 

(it) There is no LIBRARY facility as with the sPC-swAP assembler. 
The utility system overwrite assembler must be explicitly in- 
formed of the value of any and all symbols referenced by the 
overwrite but not defined within the overwrite. 

(uit) No arithmetic beyond addition and subtraction is allowed. 

(tv) Many data defining pseudo-ops of the SPc-SwWAP assembler are 
not recognized by the overwrite assembler. 

Given these restrictions of the overwrite assembler and the previ- 
ously stated restrictions of the “frozen” mode environment, the change 
implementation flow prior to Generic 8 (and therefore prior to general 
TSO usage by TSPS) went as follows: 

(t) The TR would be received by the application programmer who 
would be making the software change. 

(zt) The application programmer would generate an overwrite deck 
to fix the stated problem and test the fix by temporarily 
overwriting the generic load image in the system laboratory. 

(tit) Satisfied with the results, the application programmer would 
generate the corresponding CR and a deck of line edits for the 
PIDENT source which produced results identical to the over- 
write. 

(tv) The TR, CR, overwrite deck, and line edit deck would then be 
submitted to the generic software change review committee for 
approval. If rejected, back to step (iz). 

(v) If approved, the TR, CR, overwrite deck, and line edit deck are 
submitted to the generic system test team for independent 
overwrite testing. If rejected, back to step (iz). 

(vi) If approved, the TR, CR, overwrite deck, and line edit deck are 
submitted to pac. The line edit deck is included in the official 
line edit deck for the PIDENT(s) involved, the TR and cR are 
filed, and the overwrite deck is saved. 

This procedure was followed for each TR requiring a software change. 

When a new release of the frozen generic was required, PAG would 
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reassemble all modified PIDENTs and regenerate the generic load, 
maintaining the starting address and size of each PIDENT. This new 
load was required to exactly match the overwritten load image in the 
TSPS system laboratory before it would be released to Western Electric 
for distribution. The methodology outlined above was successful but 
possessed inherent and painful shortcomings when it was time to 
generate and match the next release of the frozen generic. The short- 
comings were primarily due to the overwrite assembler and the need 
to create a separate line edit deck producing identical results. The 
areas most susceptible to error were the manual symbol resolution and 
manual expansion of macros required by the overwrite assembler, but 
not required in the line edits. 

For Generic 8, the basic theory of this overwrite methodology, with 
its checks and approvals, was not substantially altered. There was, 
however, the development of a new tool, an Overwrite Generation 
(OVGEN) program, which eliminated the need for separate manual 
generation of overwrite and line edit decks. OVGEN allowed application 
programmers to continue to create line edits as files via QED. OVGEN 
requires the application programmer to include in the line edit file 
special control directives, identified by the programmer I.D. and a 
trouble report number, which informed OVGEN of which line edits to 
extract for overwrite generation. OVGEN, actually a combination of 
three pre-processors, an SPC-SWAP assembly, and a post-processor, 
outputs a symbolic overwrite deck for input to the utility system 
overwrite assembler. The overwrite deck contains all information 
needed for external symbol resolution. Due to the fact that spc-swaP 
is used to assemble the line edits, the application programmer can 
utilize macros, libraries for symbol resolution, the swaP data defining 
pseudo-ops, etc. In other words, for the application programmer, the 
environment is quite similar to the partial load environment, with final 
output being an overwrite deck instead of a partial load tape. 

The advantages of the OVGEN procedures in the frozen mode are 
many. 

(zt) The application programmer need only create the line edits in 
response to a TR. 

(tt) The macro facilities of sPc-SwaP are available for use. 

(tzz) Symbols used which are external to the line edit are resolved 

via pre-processing and SWAP LIBRARY facilities. 

(tv) Line edits are individually assembled. This leads to far less 
assembly problems by PAG when the full reassembly of the 
PIDENT is performed for the next release of the frozen generic. 
The final match between the new release of the frozen generic 
and the old release plus overwrites is considerably cleaner due 
to the overwrites having been generated directly from the line 
edits. 
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Ill, LABORATORY TESTING ENVIRONMENT 


TSPS programmers use the TSPS system laboratory complex to test 
and debug new or changed PIDENTs. One or more programmers work- 
ing on similar program areas will schedule time in the lab. Thus, this 
complex has been designed to provide a working environment condu- 
cive to high programmer productivity. 

Two TsPs laboratories are available to programmers. Both consist of 
the Stored Program Control (spc) No. 1A/TsPs complex, the nonresi- 
dent utility system, and call-oriented simulators. The sPc/TSPS com- 
plex allows programmers to test in an environment much like a typical 
TSPS office. The utility system and simulators provide debugging aids 
not found in a typical office. This section describes the hardware and 
software facilities which make up the laboratory complex. 


3.1 Hardware configuration 


The tsps laboratory configuration is shown in Fig. 1. This section 
discusses each component in the configuration except the simulators, 
which are discussed in Section 3.3. 


3.1.1 Stored program control (SPC) 1A 


The TsPs is controlled by the spc 1A.’ The spc consists of a processor, 
memory system, central pulse distributor, signal distributor, master 
scanner, and a maintenance control center for the man-machine inter- 
face. Each of these parts is duplicated for reliability except the main- 
tenance control center. 

The spc processor provides the control for the Tsps by executing the 
instructions in the memory. The processor cycle is 6.3 ps. The registers 
available in the processor include a 20-bit Program Address Register 
(PAR), 20-bit Address Image Register (AIR) which contains the address 
of the most recent store access, 47-bit Memory Access Register (MAR) 
for storing the information read from or written into the memory, and 
seven 20-bit index registers. The index registers are general purpose 
and may be used for any function. 

The word length of the sPc memory is 47 bits (40 bits of information 
and 7 for error correction). There are 20 bits of addressing. Nineteen 
bits select the memory word. The remaining bit determines which half 
of the word is used. 

The processor communicates to the peripherals and Tsps by three 
units: the Central Pulse Distributor (CPD) which allows the spc to send 
pulses to points in the system where fast response to an instruction is 
needed, the signal distributor which allows the spc to operate or 
release magnetic latching relays which are connected to output points, 
and the master scanner which provides status and supervisory inputs 
to the spc from the various units in the spc complex. 
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Fig. 1—tTsps system laboratory. 


The Maintenance Control Center (Mcc) consists of a control and 
display panel, a teletypewriter, and a program tape unit for loading 
the spc 1A memory. 


3.1.2 Nonresident utility system 


The utility system provides a means for easily loading and reading 
the spc memory, for debugging real-time programs in a noninterfering 
fashion, for controlling devices in the laboratory, and for transmitting 
or storing files. The advantage of this utility system over the earlier 
TSPS utilities is that the programs are nonresident to the spc and that 
debugging of programs can be done without interfering with the 
execution of the system’s real-time programs. 

The utility system is a combination of hardware and software. This 
section discusses the hardware aspects of the system, and other sec- 
tions discuss how the utility system is used for software change 
administration and program testing. The utility hardware consists of 
a support processor, a support processor interface, a noninteracting 
utility program interface console, an electronic signal distributor, and 
serial data links. 

3.1.2.1 Support processor. The support processor used in the 
utility system is a commercial minicomputer. The minicomputer uses 
the XVMDOS operating system and its peripherals include a 9-track 
magnetic tape unit, fixed head disk, 3-disk-pack bulk memories, tele- 
typewriter, high-speed printer, card reader, and paper tape reader and 
punch. 

User files and TSPS generic programs are stored on the disk memory. 
These files can be updated and additional files added by means of the 
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magnetic tape unit, card reader, or paper tape reader. The user input 
is via the teletypewriter and card reader. The output is usually over 
the high-speed printer. 

3.1.2.2 Noninterfering utility program interface console/ sup- 
port processor interface (NUPIC/ SPI). The interface between the 
spc and the support processor is the Noninterfering Utility Program 
Interface Console (NUPIC) and the Support Processor Interface (SP1). 
The NUPIC and SPI are two separate circuits but are discussed together 
because they are so closely related. 

The NUPIC interfaces directly with the spc processors to allow the 
user to monitor and control the system programs. It provides access to 
the PAR, AIR, MAR, and the index registers in each Spc processor. It 
also provides processor clock control and interrupt interfaces. The 
circuitry in the NUPIC allows the user to load the spc, read the sPc 
memory, set program matchers, and have the contents of the spc 
registers read and stored. The NUPIC has a man-machine interface 
consisting of spc register displays and manual controls. These manual 
controls are particularly useful if the support processor should fail. 
The section on program testing will discuss the debugging aids avail- 
able with the NUPIC. 

The NUPIC is controlled by the support processor via the SPI circuit, 
which provides a 2-way, high-speed data communications channel. 
Since the support processor and the spc processors have different word 
lengths and different cycle times, buffering (core memory) is provided 
in the spi. The SPI is used in conjunction with the NUPIC and the 
support processor for loading the SPc memory, reading the SPc mem- 
ory, and collecting data during program debugging. 

3.1.2.3 Electronic signal distributor (ESD). In testing programs, it 
is often necessary to have TsPs configured differently due to multiple 
generics. This means that specified circuits can be connected to or 
removed from the TSPs buses, equipment can be removed from service, 
or equipment can be put into service. The ESD provides a means to do 
this automatically. Up to 2048 distributor points can be individually 
set or reset by the support processor. These points can be used to 
control relays, lamps, and logic inputs. 

Each user can have a file on the support processor which specifies 
the generic program and how the EspD points should be set. Section 
3.2.1.2 discusses the creation and execution of the user files. 

Another use of the EsD is for physical fault insertion. This applica- 
tion is discussed in a later section on trouble location manual genera- 
tion. 

3.1.2.4 Serial data channels. Several serial data channels are 
available on the support processor. The channels are full duplex, with 
data rates up to 10K baud. The channels are used for transmitting 
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files or receiving files for storage. Presently, one of these channels is 
used for transferring user call load files to and from the microprocessor 
controlled call simulator (Section 3.3.3.2) and another is used for 
loading the writable storage unit (used in program development) of 
the Programmable Controller in the Station Signaling and Announce- 
ment Subsystem for the Automated Coin Toll Service” (acts) feature. 


3.2 Laboratory software change administration 


The desire to add new features, as well as the need to correct 
software errors, make it necessary to be able to easily change programs 
in the Tsps laboratory. This is done differently, depending on the state 
of the software base being changed. If the code is being developed into 
a new major generic issue, programmers are free to perform large-scale 
code modifications and additions. This is termed the development 
mode. If the base is already an official generic issue, only minor 
changes and additions can be made in response to specific troubles. 
This is done to minimize the need for extensive retesting after applying 
the change. This mode is termed the frozen mode. 

This section deals with the tools available for changing the TsPs 
program in the lab in both of the above modes. 


3.2.1 Development mode 


As mentioned in Section 2.2.1, the partial load is the primary means 
of changing code in the development mode. A partial load tape con- 
taining all new and changed object code is brought into the Tsps lab 
by the programmer for debugging. The programmer then uses two 
support processor programs to load the base load plus the partial load 
into the spc. These programs are DZLOAD and ALCFG (Automatic 
Laboratory Configuration). Once the desired load is in the spc, the 
NOVA (Noninteracting Overwrite Assembler) program is used to make 
minor code revisions until a new partial load tape can be generated. 

3.2.1.1 The DZLOAD program. DzLOAD is the interchange and 
comparator program for spc code and data residing on magnetic tape, 
disk, or spc memory. It allows the user to easily load and verify spc 
programs as well as create duplicate copies of SPc memory on disk or 
tape. The user may choose to store a partial load tape on disk in the 
support processor, which eliminates the need to carry the magnetic 
tape into the lab for subsequent debugging sessions. 

DZLOAD deals with only one file at a time; however, the support 
processor can also load multiple files and control the Tsps lab’s 
hardware configuration. The program that does this is called ALCFG. 

3.2.1.2 The ALCFG program. The Tsps system laboratories are 
used to develop and test hardware and software for use at TSPS 
installations in the field. The laboratory is used to simulate configu- 
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rations existing in the field and new hardware configurations under 
development. 

The ALCFG program allows the user to easily and quickly change the 
laboratory’s program and hardware configuration. The result is in- 
creased lab availability, brought about by a decrease in the manual 
action required to establish a particular configuration. The user can 
predefine a configuration and store it on a support processor disk. 
Thus, calling in the configuration definition under ALCFG will cause 
the quick reestablishment of the desired lab environment—both soft- 
ware and hardware. The lab hardware is controlled by the Electronic 
Signal Distributor (ESD). The EspD is explained in Section 3.1.2.3. ALCFG 
allows the user to easily define a particular ESD state. 

During a lab testing and debugging session, the user will probably 
uncover minor coding errors or oversights. These errors can be tem- 
porarily corrected in SPC memory using the NOVA program. 

3.2.1.3 The NOVA program. NOVA is a utility program that allows 
the lab user to overwrite SPc memory. The input to NOVA is symbolic 
SPC source code residing on punched cards or disk, or typed directly on 
the user terminal. Since the program being changed resides at a fixed 
spc memory location and occupies a fixed amount of storage space, 
code additions must be incorporated in a “patched” fashion. NOVA is 
therefore designed to manage a series of patch buffers. These buffers 
are the actual start and end addresses of spare program memory in the 
spc. Definitions of these buffers are covered in Section 3.2.2.2. 

NOVA allows the user to specify program changes in either relocatable 
or absolute fashion. NOVA reads the overwrite statements, assembles 
them into spc object code, prints a listing, and stores a binary image 
of this code on a support processor disk. This binary file is then loaded 
into sPc memory. Another binary file is also kept by NOVA, namely, 
the contents of the addresses specified in the overwrite prior to loading 
the overwrite. This file is identified by a temporary overwrite number. 
The user can therefore instruct NOVA to flush a specific overwrite out 
of sPC memory by restoring all addresses to their contents prior to the 
change. 

Many options are available to the NOVA user. Some commonly used 
ones are (Z) assemble and produce a listing, (71) assemble, produce a 
listing, and create a binary file, (iii) load the last binary file created, 
and (zv) print the old data along with the overwrite listing. Another 
option has to do with permanent overwrites. This is covered in the 
next section. 


3.2.2 Frozen mode 


The Nova-assembled overwrite is the primary means of changing 
SPC code in the frozen mode (see Section 2.2.2). The main emphasis in 
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this mode is placed on incremental change documentation and testing, 
and administration of the updated generic base load. The NOVA pro- 
gram is used extensively during this process. A programmer submits, 
in addition to TR/CR (trouble report/correction report) forms and line 
edits, a symbolic overwrite to a system test team. This overwrite is 
designed to fix a particular trouble existing in the base generic. The 
test team tests the change as a temporary NOVA overwrite and, if 
accepted, prepares to permanently incorporate it in the base generic. 

3.2.2.1 NOVA— Permanent overwrites. The mechanics involved 
in establishing a permanent NOVA overwrite are very similar to those 
for temporary overwrites. The main differences are 

1. No old data file is kept (permanent overwrites cannot be flushed 
from SPC memory). 

2. The pointers into the patch buffers are permanently changed to 
indicate that patch used in the overwrite is no longer spare 
program memory. 

In addition, a permanent record of the start and end address of 
individual patches is kept on disk. This information is extremely useful 
to PAG when generating a patched load (see Section 2.2.2) correspond- 
ing to the updated lab base load. Each patch origin must be defined to 
allow the swaP assembler to correctly assemble the patched code into 
the changed program. The NOVA permanent overwrite listing is used 
to document the change in the lab until the new PAG load and listings 
are produced. 

3.2.2.2 NOVA— Generic administration. Up to this point in the 
lab software change section, only one base load is mentioned. However, 
as stated in Section 2.1, more than one TSPS generic issue is usually 
active at one time. Consequently, NoVA must be able to properly 
change and patch programs for each active generic. This generic is 
identified by the user each time the NOVA program gets called in. NOVA 
uses this identification to access a set of PIDENT and PATCH files unique 
to that generic. The administration of these PIDENT and PATCH files is 
handled by a portion of NOvA, called PIDAM. The system test group 
usually takes care of this administration. PIDAM allows the user to 
define and update the PIDENT and patch files for each generic. These 
files contain a list of all PIDENTs that make up the generic issue along 
with their start and end addresses, available patch buffers, a store 
patch map (i.e., a map linking spc programs to a specific patch buffer), 
and a list of all permanently loaded patches (see Section 3.2.2.1). 


3.3 Laboratory program testing 


After the spc has been loaded with a new generic program (devel- 
opment mode) or changes made to an existing generic program (frozen 
mode), the programmer is ready to begin testing. The following sec- 


SOFTWARE DEVELOPMENT TOOLS) 1323 


tions describe the hardware, software, and simulators available to the 
programmers for testing programs. 


3.3.1 Hardware for program debugging 


The NuPIc discussed in Section 3.1.2 gives the user extensive pro- 
gram debugging tools. These tools include matchers, visual displays, 
and processor controls (Fig. 2). 

The matchers available with the NUPIc include: 

Address Matchers—There are nine address matchers (one manual) 
which can be set to indicate when a specified program address is 
executed or when a specified data address is read or written. 

Range Trap Matchers—Two range trap matchers are available. 
These matchers will indicate when any address within a range of 
program is reached or when any address within a range of data is 
accessed. 

Bit Matchers—Two 20-bit matchers allow the programmer to match 
against an address, contents of a memory location, or the contents of 
an index register. The bit pattern to be matched against can have an 
associated mask. This mask will indicate which bits in the pattern are 
“don’t cares.” 

Peripheral Matcher—The peripheral matcher is used to indicate 
when a particular peripheral order accesses a particular peripheral 
unit. The peripheral unit address can have an associated mask. 

Each of these matchers can be set manually via keys on the NUPIC. 
All but the manual matcher can also be set automatically. When a 
matcher “fires,” the contents of the spc registers can be collected by 
the support processor, analyzed, and printed on the high-speed printer. 

The matchers can be set up with different options which will be 
executed when the matcher fires. These options can be interfering and 
noninterfering. The noninterfering options include register snaps and 
transfer traces. The transfer trace gives a record of every transfer that 
occurs in the program once the matcher fires. 

The interfering options cause an interrupt in the spc program 
execution and transfer of control to the spc resident utilities. The 
options include doing a write into unprotected memory, dumping 
portions of memory, writing to registers, jumping to a different address, 
and stopping the spc. 

The visual displays on the NUPIC include binary lamp displays for 
the major points in each sPc processor such as the index registers and 
buses. Octal displays are provided for the registers most often used. 
These include the PAR, AIR, MAR, selected matcher address, and 
relocatable address (least five significant digits). The PAR, AIR, and 
MAR displays are available for each processor. 
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Several manual control functions are provided to allow the user to 
selectively control either or both sPc processors. 
(t) The user can stop or start the processor clock and can step 
through instructions one cycle or one phase at a time. 
(it) Instructions, data, and scanner answers can be inserted. 
(tit) Matchers can be set up. 
(iv) Utility interrupts can be generated and flags provided for the 
spc resident utility programs. 
(v) Transient store errors can be simulated. 
(vt) The processors can be split into two independent systems. 


3.3.2 Software for program debugging 


Facilities exist in both the support processor and the spc to aid in 
TSPS program debugging and testing. The most useful of these resides 
in the support processor and is called sPcppT (Stored Program Control 
Dynamic Debugging Tool). This program activates matchers and 
traces via the NUPIC to give the user information about program flow 
in the spc. Another useful support processor program is AMADMP 
(Automatic Message Accounting Dump). This program aids call proc- 
essing programmers by providing formatted AMA information at the 
completion of a call. Finally, spc-resident code assembled as a special 
set of Feature Assembly Debugging Aids (FADA) allows the program- 
mer to selectively control the execution of TSPS programs. 

3.3.2.1 The SPCDDT program. SPCDDT is used to set address 
matchers, range traps, bit matchers, and a peripheral matcher in the 
NUPIC circuit (see Section 3.1.2). The user has the ability to control 
certain actions before and after a matcher fires. Some of these options 
are: 

(t) Jump to a program address when a matcher fires. 

(ti) Dump the contents of specific spc memory areas on the line 
printer when a matcher fires. 

(zit) Write information into an sPc memory location when a matcher 
fires. 

(tv) Start or end a transfer trace when a matcher fires. 

(v) Selectively print trace information on the line printer. 

(vi) Continually store trace information in the core memory of the 
SPI circuit (see Section 3.1.2.2). If the core fills, overwrite it 
with the more recent information (overlay mode). Freeze it and 
send the contents to the support processor for printing when 
another matcher fires. 

Option (vz) is a particularly useful feature. It allows the programmer 
to monitor the entire flow of one (or more) program(s), and print out 
only the flow prior to an interesting event. 

3.3.2.2 The AMADMP program. AMADMP provides formatted AMA 
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information on the support processor line printer at the completion of 
a TSPS call. This information is very useful to a programmer in 
debugging call processing or billing-oriented software. 

Normally, the AMA Data Accumulation Program (AMAC) stores the 
billing information in buffers in TSPS memory. When a buffer is full, 
AMAC activates another program which records all buffered data on 
magnetic tape. This tape must then be processed on an off-line 
computer. The delays and logistics involved in this procedure make it 
undesirable for debugging purposes. Consequently, AMADMP was writ- 
ten during the development stage of the Remote Trunk Arrangement 
(RTA) feature of TSPS Generic 7. 

AMADMP uses the NUPIC to activate two matchers in the AMAC 
program. One matcher fires at the start of AMAC’s recording of the 
billing information and the other fires after all information has been 
buffered for a call. Using the information appearing in the SPC registers 
at the time the matchers fire, AMADMP requests a dump of the buffer 
locations used by AMAC. The data from these locations are then 
formatted in the support processor to make it more readable, and then 
printed on the line printer. 

3.3.2.3 The FADA feature. FADA is a collection of debugging soft- 
ware that can be assembled into a development base load. It consists 
of special code added to generic TSPS programs as well as a special 
PIDENT (ECDB). This code does not get released officially for use in live 
TSPS offices. 

FADA was developed during the early stages of Generic 7 as an aid 
in the recovery of new program loads and a debugging tool. It accom- 
plishes this by allowing the user to selectively inhibit execution of 
many program functions. This capability makes it possible to simulate 
many low probability events, cause race conditions, and exercise 
program failure legs. 


3.3.3 Simulators 


3.3.3.1 Single-call simulators. Many times in testing programs, 
the programmer needs the ability to place a single call through the 
TSPs. Two types of test facilities are available for making single calls. 
The first of these facilities is the “single-line” simulator. This simulator 
consists of a local (calling) telephone connected to the local office side 
of the simulator and the toll (called) phone connected to the toll side 
of the simulator. The local and toll sides of the simulator are connected 
to a TSPS incoming trunk. This trunk is dedicated to a particular traffic 
type. For each traffic type (coin, hotel/motel, RTA), there is a single- 
line simulator. 

Calls are placed by the programmer in the same way a customer 
would make a particular type of call. The simulator performs all 
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necessary signaling required by Tsps. The call is recognized by TSPs 
and handled appropriately by routing it to an operator’s position or by 
connecting the called telephone. 

The single-line simulator is used for calls which are to be handled 
normally. The simulator generates the correct KP, Start (ST) digit, and 
Automatic Number Identification (ANI) digit for the call. However, 
there are times when the programmer must have more control over 
the call. For instance, the programmer may wish to test a call using an 
improper ST digit or ANI digit. In these cases, the manual trunk test set 
(also known as the “Burelback Box’’) is used. 

The manual trunk test set allows the programmer to place a single 
call and to have control over the entire call. The programmer selects 
the type of TsPs trunk circuit to be used and the call type. By operating 
switches, the programmer simulates seizure by the local office and 
responds to supervision from TSPs by keying in the KP digit, the call 
digits, a ST digit, an ANI digit, and the calling digits. When the toll side 
of the trunk is seized by Tsps, the programmer generates the toll 
supervision signals to TSPS. On ACTS calls, the coin tones can also be 
generated. 

3.3.3.2 Multiple-call simulators. There are program bugs which do 
not show up until there is a substantial traffic load on the system. In 
TSPS testing, a simulated load can be generated by the Electronic Load 
Box (ELB) and the Microprocessor Controlled Load Box (MICLOB). 
Both of these “load boxes” automatically generate calls on multiple 
TSPS trunk circuits. Each load box simulates the functions of both the 
local and toll offices. 

The characteristics of the ELB are: 

(t) Generates up to 14 simultaneous calls. All calls must be the 
same type and the same length. 
(ti) Can generate 1800 calls per hour. 

(tit) Works with mF (multifrequency) trunks, 2-wire, or 4-wire, loop 

or E&M signaling. 

To use the ELB, the user selects the number and the type of the calls 
desired. If more than one call type is required, another ELB must be 
used. To provide the user with more flexibility in setting up a call load 
and to provide the capability for coin signaling for ACTS, the MICLOB 
was developed. MICLOB (Fig. 3) has the following characteristics: 

(t) It generates up to 32 simultaneous calls of any call mix the user 
wishes. 

(it) The call types include coin, noncoin, hotel/motel, and inter- 
national. 

(zit) All call parameters are under user control. 

(tv) It works with either 2-wire or 4-wire trunks with MF or DP (dial 

pulsing) signaling and with loop or E&M supervision. Other 


1328 THE BELL SYSTEM TECHNICAL JOURNAL, JULY-AUGUST 1979 





Fig. 3—Microprocessor Controlled Load Box. 
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trunk types can be easily handled by modifying the microcom- 
puter program and providing the proper trunk interface. 

(v) The call load can be as high as 10,000 calls per hour for short 
calls. 

The user sets up his call load by entering the call parameters for 
each trunk via a teletypewriter or a terminal. Once the load is estab- 
lished, the calls can be started or stopped individually or as a group. 
The user can save his call load parameters on the support processor’s 
disk via a serial data link (Section 3.1.2.4). This call load can be 
reloaded at a later time. This save/load capability allows users to set 
up a call load without entering the information via the teletypewriter 
each time. 

Another feature of the MICLOB is the error messages printed on the 
TTY or terminal whenever calls do not proceed properly. These mes- 
sages can alert the user to a problem with a trunk circuit or a MICLOB 
circuit. 

In a testing environment where a heavy load is required, the ELB 
can be used to generate a background load of a particular call type. 
The MICLOB can be used to generate a load of special calls or of call 
types not possible with the ELB. In this manner, the TsPs programs 
can be exercised in the lab much like a live system. 

3.3.3.3 Operator simulators. Operator simulators are used to sim- 
ulate operator actions on calls arriving at positions. These simulators 
are used when a call load is generated containing calls which require 
operator assistance. The simulators recognize the call types arriving at 
the position and generate the required keying sequences. There are 
two types of operator simulators used in Tsps. The older simulator is 
hardwired. It can handle all call types except acts. Each of these 
simulators requires an actual position to operate. 

The new Microprocessor Operator Position Simulator (MOPS) can 
handle all call types. Each call type can be handled differently, new 
call types can easily be added, and existing calls can easily be changed. 
This simulator can work with or without an actual position available. 
In this way, less positions are required in the laboratory. The advan- 
tage of having calls go to an actual position is that one can observe 
how the simulator is handling calls or one can manually handle a call 
if necessary. These functions can be duplicated via a terminal con- 
nected to the simulator. 

The lamp and display orders sent to a simulator position by TSPs 
during a call can be converted to lamp names and digital displays and 
printed on the terminal. By monitoring a particular simulator position, 
the programmer can observe calls going to the position. The keys on 
the terminal are programmed to act as position keys so that the 
programmer can also manually handle a call if desired. The terminal 
can be remoted if necessary. This feature is useful when the TSPs 
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operator positions are not at the same location where program testing 
is being performed. 


3.4 Trouble location manual (TLM) generation 


The Trouble Location Manual (TLM) contains Trouble Location 
Numbers (TLN) for a circuit or subsystem. Associated with each TLN 
is the location of probable failing circuit packs in the circuit. These 
numbers which are an output from the diagnostic program are used to 
assist craft in fixing a faulty circuit. 

The generation of a TLM for each circuit or subsystem requires that 
faults be physically inserted in these circuits. The diagnostic program 
for the circuit being faulted is run. The results from the diagnostic are 
used to generate the TLN. The collection of TLNs and faulted circuit 
locations make up the TLM. 

Originally, in TSPS, most circuit pack faults could be inserted at the 
connector. However, with the introduction of RTA and the IGFET 
(Insulated Gate Field Effect Transistor) memory, circuit packs become 
much more complex. They contained many integrated circuits in Dual 
In-Line Packages (pip). All necessary faults could not be inserted at 
the connector. To insert faults in the newer circuit packs and to speed 
up the TLM generation process, a minicomputer-controlled fault inser- 
tion technique was developed. This technique, which consists of fault 
insertion hardware and software, is discussed in the following sections. 


3.4.1 Physical fault insertion 


The type of faults inserted in the circuits are opens and shorts to 
desired voltage levels on the circuit pack connectors and the pins of 
the pips on the packs. . 

The circuit pack which is being faulted is a special version of the 
standard circuit pack in that the integrated circuits are socket- 
mounted. The circuit pack is mounted in a special extender board 
which is plugged into the circuit pack connector. The DIPs on the 
circuit pack have “daughterboards” inserted between them and their 
sockets. Both the extender board and “daughterboards” have relays 
which can be controlled to open or short the circuit pack connector 
pins and the DIP pins. 

These relays are controlled by the support processor by setting 
selected points in the EsD. The fault insertion hardware decodes this 
information to operate the selected relays and thus insert the desired 
fault. 


3.4.2 Diagnostic control and raw data accumulation 


The support processor contains software to control automatic phys- 
ical fault insertion and the spc diagnostic programs. It also contains 
routines to gather the test results, or raw data, from these diagnostics. 
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These results are combined into a data base used to produce system 
TLMs. The support processor software designed to control these proc- 
esses is called McFIT (Minicomputer Controlled Fault Insertion Tech- 
nique). The MCFIT program, together with special code in the spc to 
interface with system diagnostics, make up the automatic physical 
fault insertion control software. 

3.4.2.1 The MCFIT program. MCFIT was designed to allow rapid 
fault insertion and TLM generation. The majority of faults to be 
inserted are stored in a data base on the support processor’s disk. This 
data base consists of all standard faults that are defined for each type 
of DIP used in the circuit being faulted. Thus, the user must only input 
the layout of the circuit pack to be faulted and any modifications to 
the standard fault list. McFIT automatically controls the faulting of the 
entire pack, requiring manual intervention only to move the fault 
insertion hardware to the next pack. 

Once the user has specified the pack layout, McFIT retrieves the 
correct list of faults from disk and applies any necessary modifications. 
This list, together with the subsystem identification and circuit pack 
location, comprise the MCFIT “work file.” MCFIT then executes a fault 
insertion program which sequentially inserts all faults appearing in the 
work file. This program controls the fault insertion hardware, activates 
a special spc program which requests diagnostics on the specified 
subsystem unit, and records the failure data on the support processor’s 
magnetic tape unit. It also prints summary data on the line printer. 
These data point out unexpected diagnostic aTps (All Tests Passed) 
and inconsistent failure data for the user to examine. 

3.4.2.2 SPC interface software. As mentioned above, the MCFIT 
program activates a special spc program to request diagnostics. This 
SPC program is not part of the official generic, but is loaded into 
memory at the start of each fault insertion session in the lab. The 
diagnostic is requested through the NUPIC/SPI interface. An interrupt 
is generated in the spc which transfers control to this diagnostic 
interface program. This program sets the appropriate bits in the 
diagnostic request words and status words corresponding to the sub- 
system unit being faulted. The diagnostic sequence proceeds normally 
in the spc with one exception. Normally, each diagnostic transfers 
control to the spc Diagnostic Output Control Program (DocpP) to print 
the pass/fail data on the maintenance teletypewriter. This special 
program, however, intercepts the data passed to DocP and sends them 
to the support processor via the NUPIC/SPI. 


IV. CONCLUSION 


Effective software development depends very heavily on adequate 
development tools and test facilities. The tools and facilities described 
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in this paper came about through an evolutionary process. They 
started out in a much more basic form and were improved and 
expanded many times before they reached their present state. Thus, 
effective support software and hardware requires ongoing develop- 
ment. This point must be kept in mind so that programmer productiv- 
ity can continue to improve. 
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This paper describes the verification and evaluation procedures 
followed in the development of new features for the Traffic Service 
Position System (tsps). Beginning with the definition of new feature 
requirements, these procedures are adhered to throughout the TsPs 
development cycle. Hardware and software designs are reviewed to 
verify that all requirements are met and to ensure that Bell System 
standards for reliability are maintained. Finally, both system labo- 
ratory and site testing are performed to verify the proper implemen- 
tation of each new feature and to evaluate the overall performance of 
the TSPS. 


I. INTRODUCTION 


A significant part of the effort required for any switching system 
development involves determining whether the system performs 
properly. The ultimate judge of system performance is the user. In 
making this judgment, the user considers both system reliability and 
maintainability. Since Bell System standards for service are very high, 
measures of acceptable performance are rigorous. Thorough plans are 
made to ensure that switching systems provide this required high level 
of performance. These plans begin with the initial concept of a switch- 
ing system or new feature and continue throughout the development 
process. Every design decision is based on providing the best possible 
service at the lowest possible cost. Each decision is evaluated for its 
impact on the customer who uses the switching system and on the 
operating company that must administer and maintain it. 

This paper discusses the methods used to verify and evaluate system 
performance of the Traffic Service Position System (Tsps). It also 
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describes the facilities specifically designed to support the verification 
and evaluation process. 


ll. STAGES OF THE TSPS VERIFICATION AND EVALUATION PROCESS 


The verification and evaluation process for new TSPS features in- 
volves all aspects of system development. This process begins with the 
determination of feature objectives and continues with the verification 
that the design requirements for each new feature are consistent with 
these objectives. Finally, the system is tested to ensure that the 
implementation reflects the design requirements. This process is di- 
vided into several stages. The stages of verification and evaluation 
discussed in this article are (i) requirements reviews, (ii) design 
reviews, (iii) circuit analysis or program reviews, (iv) unit testing, (v) 
integration testing, and (vi) system testing. Figure 1 shows these six 
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Fig. 1—Six stages in the Tsps verification and evaluation process. 
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stages and how the results of each stage are used in subsequent stages 
of the development. 

The first stage of the verification and evaluation process begins 
when a new TSspPS feature or system capability is proposed. Each new 
feature is analyzed to determine the service and maintenance require- 
ments that must be satisfied. This analysis can be very extensive for 
some new features, such as the Automated Coin Toll Service (Acts) 
feature. To perform this analysis for ACTS, an in-service TSPS was 
modified to simulate acts for a comprehensive human factors trial.' 
The results of this trial guided the formulation of the requirements for 
ACTS. These requirements are documented in development require- 
ments memoranda and form the basis for detailed design and devel- 
opment. 

The detailed design and development of a new feature is generally 
accomplished by partitioning the feature into functional units which 
are then assigned to development teams for implementation. Contin- 
ued division of responsibility within a team for the development of a 
functional unit is dependent on the complexity of that unit. This 
partitioning applies to both hardware and software portions of the 
system. 

The second stage of the Tsps verification and evaluation process 
begins when design reviews are held to determine if the conceptual 
aspects of each functional unit are consistent with the overall system 
requirements. Once the architectural design of the functional unit has 
been evaluated in this manner, the development team begins the 
detailed design of the functional unit. The design of each element in 
the functional unit is reviewed. Depending on the number and com- 
plexity of functional unit interfaces, members of other Tsps develop- 
ment teams may participate at this point in the process. After this 
review, development specifications memoranda and circuit descrip- 
tions are usually written documenting the detailed design. 

The hardware development proceeds with the generation of circuit 
schematic diagrams and the specification of the circuit components 
used in constructing the circuit. The layout of the circuit components 
and their interconnections are specified, and prototype circuits are 
built. The prototype circuits are tested off-line from the system to 
ensure that they perform as required. Manufacturing tests are also 
generated for digital circuits using a logic simulation program.’ After 
these tests and prototypes of the digital circuits are verified with a 
circuit pack tester, testing begins in the system laboratory. Once the 
circuit is verified to operate in accordance with the design intent, 
manufacturing and factory test information is transmitted to Western 
Electric. This activity is scheduled so that standard Western Electric- 
supplied hardware will be available when site testing begins. 
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The software development is done in parallel with the hardware 
development. After each program is written, a program review is 
conducted (i) to ensure that all development requirements are met; 
(ii) to verify that the interfaces between programs are correct; and (ii7) 
to check that each program instruction is correct. Problems identified 
and corrected during this program review require much less effort than 
if they were left to be resolved during later stages of the verification 
and evaluation process. 

The fourth stage in this process is the formulation of functional tests 
which utilize special test facilities (see Section III) and which ensure 
that each functional unit meets the design requirements. Upon the 
completion of unit testing, the fifth stage of the verification and 
evaluation process occurs when integration testing is performed. In- 
tegration tests ensure that each functional unit performs in a total 
system environment. Specifically, interactions between functional 
units and hardware-software interfaces are emphasized. Once the 
integration tests have been successfully run, the functional unit designs 
are considered frozen, in that changes to a functional unit can only be 
made on a more formal and controlled basis. The frozen functional 
units are now ready for system testing, the sixth and last stage in the 
verification and evaluation process. 

During system testing, additional functional tests are written, and 
the total set of functional tests are performed by an independent group 
to ensure that any biases held by the design engineers are not reflected 
in the interpretation of test results. Beginning with this phase of TsPs 
testing, every change introduced into the system—hardware or soft- 
ware—must be initiated by a trouble report which specifies the seri- 
ousness of the problem so that corrections can be generated on a 
priority basis. Changes must be submitted in a formal manner and 
approved by a special committee called the change review committee. 

Beginning with the system testing phase of the verification and 
evaluation process, each change is tested incrementally. That is, the 
correction to each problem, when possible, is considered an independ- 
ent entity. Each correction can be rejected if not deemed appropriate 
by either the change review committee or the system testers. This 
procedure is used (z) to provide a high degree of visibility to all changes 
being introduced into the system, (iz) to provide a procedure whereby 
each change is individually and thoroughly tested, and (iii) to provide 
a procedure whereby design engineers can make changes without 
repeatedly going through the integration process. 

To this end, each change submitted by the design engineer must be 
accompanied by a very specific test procedure which has been verified 
before the change is submitted. System testers then take great care to 
ensure that the test procedure is appropriate and that the change does 
not invalidate a previously verified functional capability. In some 
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cases, this can only be done by repeating a long series of previously 
completed functional tests. This verification and evaluation process is 
greatly enhanced by a comprehensive set of test facilities discussed in 
the following section. These test facilities are available to both design- 
ers and system testers. 


lll. SYSTEM LABORATORY TESTING 


TSPS verification and evaluation is done at Indian Hill using two 
system test facilities. Each test facility contains a TSPs and its associ- 
ated peripheral subsystems (i.e., a Position Subsystem No. 1,° Position 
Subsystem No. 2,* Remote Trunk Arrangement,’ Station Signaling 
and Announcement Subsystem*’—see Fig. 2). Minicomputers and var- 
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Fig. 2—Traffic Service Position System No. 1. 
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ious microprocessor-controlled circuits are utilized to produce the 
desired hardware and software environment.’ In this environment, the - 
system laboratory user can control and monitor the operation of the 
TSPS. Figure 3 shows one of the TsPs system laboratories at Indian 
Hill. 

One aspect of controlling the TSPs operation is to establish the 
desired hardware and software configuration. The minicomputer pro- 
vides three major capabilities for reconfiguring or modifying the sys- 
tem. First, the minicomputer provides the capability to load the TsPs 
with a new program, with the system’s program stores being automat- 
ically reconfigured to match the memory requirements of the new 
program. Second, portions of the TSPS program can be modified with 
changes assembled by the minicomputer. This capability is used ex- 
tensively in the incremental testing of modifications to frozen pro- 
grams. Third, automatic fault insertion by the minicomputer is used 
to exercise system diagnostics in the preparation of trouble locating 
manuals. These manuals are used in conjunction with diagnostic 
outputs to identify hardware faults. The automatic process by which 
these faults are inserted helps to increase trouble locating manual 
resolution by allowing efficient generation of a large number of sample 
diagnostic results. 

Once the desired hardware and software configuration has been 
established, the minicomputer can then be used to monitor the oper- 
ation of the Tsps. Data associated with a specific event or combination 
of events can be recorded and later retrieved by the minicomputer. 
When correlated with the normal system responses such as teletype- 
writer messages, those data can be used to resolve problems or to 
confirm the proper operation of the TSPs. 

An important part of testing Tsps features is ensuring that system 
interactions involving customers and operators are correct. Many 
inputs processed by a TSPS result from these interactions. To provide 
similar inputs in the system laboratory, stimuli comparable to those 
generated by customers and operators are produced using system 
utilities. A microprocessor-controlled facility is provided to simulta- 
neously generate calls from many’ trunks. Both the traffic-handling 
characteristics of each trunk and call types can be changed under 
program control. Facilities are also provided to simulate the local and 
toll offices associated with a single TsPs trunk, thus allowing a labo- 
ratory user to completely control all stages of an individual call. 
Microprocessor-controlled operator simulators are provided to auto- 
matically handle calls at TSPs operator positions. In addition, calls can 
be handled manually at an operator position, thereby allowing the 
system laboratory user to test unexpected operator sequences. 

System testing is divided into functional testing and system evalu- 
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Fig. 3—The tsps System Laboratory. 


ation. Ideally, it would be desirable to write and perform functional 
tests in the system laboratory for each call processing and maintenance 
situation the TsPs will encounter. In practice, however, this is impos- 
sible. Consequently, during system testing, additional effort is required 
above and beyond the analysis of functional test results. This effort is 
referred to as system evaluation. In terms of cause and effect, func- 
tional testing involves setting up a prescribed set of initial conditions 
and then determining whether or not the proper response occurs. 
However, system evaluation involves observing every improper system 
response and then determining the cause of that response. This can be 
a difficult task, which at times is more of an art than a science. 
Reproducibility is a primary requirement for identifying the cause of 
a problem. Problems discovered during functional testing are generally 
reproducible, since a set of initial conditions have been specified for 
running each functional test. However, problems encountered during 
system evaluation frequently do not meet this reproducibility criterion. 
As a result, much more analysis of these types of problems is required. 

During system evaluation, several indicators are used to determine 
that a problem exists. These indicators are: 


(t) Unexpected teletypewriter output messages. 
(it) Loss of service of a hardware unit to the system for no appar- 
ently valid reason. 
(iit) Unexplainable maintenance or call processing activity. 


The audit messages’ printed on the teletypewriter are a primary 
indication of system problems. Each audit message generally signifies 
the presence of some program error resulting in an inconsistency in 
unprotected memory. This memory is continuously updated by differ- 
ent programs to reflect the current state of the system. A detailed 
analysis of the audit messages will sometimes indicate what caused 
* the error condition. The debugging capabilities of the minicomputer 
described above are particularly helpful in resolving this type of 
problem. With these capabilities, system activity which occurred be- 
fore the audit program detected the error can be analyzed, and the 
cause of the problem can be identified. 

The system laboratory provides a controlled environment where 
interfaces external to the Tsps have been simulated with system 
utilities. Although it is possible to test most aspects of the TSPs 
operation in this environment, increased confidence is built when new 
features are tested at a newly installed Tsps which interfaces with 
actual local and toll offices. For these and other reasons, the verifica- 
tion and evaluation process is continued at a test site. 
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IV. THE SITE TESTING INTERVAL 


Each new generic is tested at a Tsps that has not been cut into 
service. This Tsps has been fully engineered by operating company 
personnel, and the hardware has been installed by Western Electric 
during a normal installation interval. Bell Laboratories testing of a 
generic at this pre-cutover TSPS evaluates the new features in a fully 
equipped Tsps. It also verifies the accuracy of the information provided 
to Western Electric and the operating companies on these new fea- 
tures. Testing is done with both local and toll offices to ensure that no 
interface problems exist. The length of the site test interval varies 
depending on the number of features being tested, amount and com- 
plexity of the new hardware, and size of the program change. Table I 
summarizes the test site, major new features, and size of the program 
change for each of the recent TSPS generics. 

Testing at the site involves reverifying specific operational and 
maintenance capabilities for all new features, with the objective of 
determining whether or not the requirements for each feature are met. 
In particular, testing focuses on verifying interfaces with local and toll 
offices. Regression testing is also performed to ensure that previous 
TSPS capabilities are not adversely affected by the new features. Since 
site testing is performed after new feature development has been 
completed, problems identified at the test site are generally more 
subtle than those previously uncovered during system laboratory 
testing at Indian Hill. Furthermore, by the beginning of the site test 
interval, the hardware design has already been proven in the system 
laboratory. As a result, during this interval the majority of problems 
identified are in the software. Most are not due to any significant 
design problems and are easily corrected. 

Both functional testing and regression testing at the site are done in 
a systematic manner; a specific set of tests are performed for each 


Table I—Recent TSPS generics 


Size of Pro- 
gram Change 
(40-bit 
Generic Test Site Major New Feature(s) Words) 
Generic 7, Is- Syracuse, New Remote Trunk Arrangement, Po- 60,000 
sue 1 York sition Subsystem No. 2 
Generic 7, Is- Saginaw, Michi- Selective Call Screening, more 5,000 
sue 2 gan than twenty stores on a bus 
Generic 8, Is- Phoenix, Arizona Automated Coin Toll Service 40,000 
sue 1 


Generic 8, Is- Montgomery, Al- | Automated Coin Toll Service with 7,000 
sue 2 abama Remote Trunk Arrangement 
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feature, the results are observed, and these results are analyzed. The 
amount of detail with which functional test results are analyzed at the 
test site is minimal. Instead, any functional tests which fail are docu- 
mented in trouble reports which are then sent back to the developers 
at Indian Hill. Extensive analysis at the test site is restricted to 
problems uncovered during system evaluation. In general, the exact 
conditions required to bring out these types of problems must be 
determined at the test site. 

The combination of system laboratory testing and site testing during 
this interval complement each other in the verification and evaluation 
of a TSPS generic. In the system laboratory at Indian Hill, emphasis is 
placed on testing individual changes being made to correct specific 
problems. However, as indicated above, effort at the test site is oriented 
toward verifying and evaluating functional capabilities rather than 
testing changes or corrections. 

The test facilities provided at the major test sites are comparable to 
those permanently installed in the system laboratories at Indian Hill. 
These facilities include the minicomputer, call generation capabilities, 
and operator simulators described in Section III. Additional capabili- 
ties are also provided to remotely control these test facilities so that 
testing can be done from one location. 

The number of problems identified from the time the hardware and 
software were frozen until the completion of site testing is shown in 
Table II for each of the recent Tsps generics. These totals are broken 
down into: (i) problems identified at Indian Hill in the system labora- 
tory and (iz) problems identified at the test site. 

At the completion of the site testing interval, responsibility for 
monitoring system performance is given to TsPs field support person- 
nel. In addition to continuing the evaluation of Tsps and new feature 
performance, field support personnel are responsible for updating the 
system with any necessary changes. To assist in these efforts, the 
TSPS’s maintenance teletypewriter output can be transmitted to the 
TSPs Diagnostic Center at Indian Hill. Problems detected from this 
output or reported by the operating company are analyzed, and cor- 


Table !l—Trouble reports written through the completion 
of site testing 


TRs Written 
at the Base TRS Written at 


Generic Location the Test Site Total 
Generic 7, Issue 1 600 615 1215 
Generic 7, Issue 2 33 20 53 
Generic 8, Issue 1 565 800 1365 
Generic 8, Issue 2 108 58 166 
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rections are generated by designers working in conjunction with field 
support personnel. 


V. SYSTEM CAPACITY 


The addition of each new feature to TsPs has an impact on the real- 
time capacity of the Tsps. Overall system real-time capacity varies for 
each TSPS installation based upon the hardware configuration used 
and the particular call mix being processed. Each new feature is 
evaluated during the development cycle to determine its impact on 
system capacity. This evaluation is verified at the first in-service office 
or the first office close enough to capacity for a verification to be made. 
The real-time capacity estimation and verification process is extremely 
important due to its effect on the long-range planning of the operating 
companies. To assist the operating companies in their analysis of an 
individual office’s real-time capacity, a program called TSPSCAP is 
available. This program runs on an off-line computer and is updated 
with each generic to reflect the addition of new features. 


VI. SUMMARY 


System verification and evaluation is a process that is interwoven 
with all aspects of the development of new Tsps features. From the 
inception of the idea for a new feature, development requirements are 
evaluated to ensure a proper understanding of the proposed capabili- 
ties and to verify that the proposed design will provide these capabil- 
ities. After formal reviews, these requirements are specified in devel- 
opment requirements memoranda, and the design is specified in de- 
velopment specifications memoranda and circuit descriptions. Next 
the design is implemented and each functional unit is verified in the 
system laboratory. Before the commencement of site testing, both 
hardware and software are placed in a frozen mode, after which all 
changes to the system are verified through a formal procedure. Site 
testing is done in a pre-cutover TSPS engineered by an operating 
company with hardware supplied and installed by Western Electric. 
During site testing, functional tests are run to verify the proper 
implementation of all new features and regression tests are run to 
ensure the proper operation of previous TSPS capabilities. In addition, 
system evaluation is done before the site is cut into service, thus 
resolving many of the more subtle problems. Finally, an analysis of 
the real-time effect of each new feature is made after cutover to 
confirm the theoretical analysis made prior to cutover. 

This verification and evaluation approach is followed for each new 
TSPS feature. Adherence to this methodology allows new TsPs generics 
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to be properly verified and evaluated, thereby insuring Bell System 
customers of the best possible service. 
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The evolution of operator training facilities for Tsps No. 1 has 
involved the development of new program-controlled positions which 
have much greater flexibility and reliability than preceding training 
equipments. These PROCON-controlled positions and associated facil- 
ities are now the standard means for training TsPs operators. Coin- 
cident with the development of these facilities, a minicomputer system 
for generating master training tapes was designed to facilitate the 
generating of new training tapes and modifying existing ones to add 
new operating features. 


Since the beginning of telephony, there has been a need to train 
switchboard operators in the procedures required to handle and com- 
plete telephone calls. These procedures started with “on the job” 
training and gradually improved over the years to specialized training 
facilities to give the trainees the ability to handle calls before they sat 
down at a switchboard handling traffic. 

With the advent of the crossbar tandem Traffic Service Position in 
1961, a new specialized training facility (100A trainer) was designed to 
train operators in the basics of handling traffic on this new type of 
switchboard (Fig. 1). This consisted of an operator position with two 
equipment cabinets. One of the two cabinets contained a paper tape 
reader, a magnetic tape player, power supplies, and racks for tapes. 
The second cabinet contained densely packaged electromechanical 
and solid-state circuitry which performed the necessary trainer func- 
tions under control of information on the magnetic and paper tapes. 

Customer calls were simulated by verbal passages on the magnetic 
tapes which also provided synchronizing tones to start the paper tape 
reader. The paper tape reader and the magnetic tape player were 
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Fig. 1—Operator training equipment. 


additionally controlled by the trainee sitting at the training position 
responding to simulated calls. 

In effect, the training system was a simulator which could duplicate 
nearly all types of calls handled by a Tsp. Different types of calls were 
simulated by different input tapes which were loaded by supervisory 
personnel. 

With the development of Tsps No. 1, this 100A system was modified 
to provide added capabilities and was classified as the 100B trainer. 
Essentially, however, the basic operating principles and the physical 
appearance of the new trainer remained the same. This system has 
been used to train operators on TSPs call-handling procedures since its 
first application in 1969. However, as new features have been added to 
the TSPS, corresponding equipment modifications have been required 
in the relay circuitry. As there are over 2000 of these trainers in the 
field, this is a significant problem. In addition to this, the design of 
these changes becomes more difficult as control logic becomes more 
complex and as precise operating characteristics of the trainers is 
required. 

To overcome these problems, a new programmable 100C trainer 
system was designed. Programmability enables new Tsps features to 
be introduced to the simulator quickly with few or no hardware 
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modifications. This system also provides a supervisory function not 
available on the 100B trainer. Furthermore, it uses standard 100C 
operator positions which can also handle regular traffic when not used 
as trainers. 

This new trainer system shown in Fig. 2 consists of a maximum of 
eight training positions and one supervisory position. Each position 
can be switched to handle normal traffic. These positions can also be 
dedicated for training only and supplied on a stand-alone basis requir- 
ing no association with any chief operator group or TSPS No. 1 System. 
A photograph of a training position is shown in Fig. 3. 

A standard 100C position is converted to a trainer by a wiring option 
added to the existing local cable wiring, and an applique column (Fig. 
4) added to the rear of the position. This column contains a micro- 
processor called the programmable controller (PROCON) (Fig. 5), which 
provides the necessary control functions for the trainer. In addition to 
this, translator and temporary memory boards, voice and tone detec- 
tors, tone generators, I/O logic control circuitry, diagnostic indicators, 
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Fig. 3—100C training position. 


switching circuitry, supervisory interface control, and isolation cir- 
cuitry are all contained in the column (Fig. 6). 

To provide the necessary combined data and voice inputs to the new 
trainer, a special cassette tape reproducer was required. This repro- 
ducer is largely based on conventional technology in the audio/visual 
and training fields. The prerecorded tape is in the standard Phillips 
cassette stereo configuration. However, several special features were 
required in this application: 

(t) A precise high speed reverse to enable the trainee to return to 
the beginning of a call pattern on the tape (called the “repeat” 
mode). 

(tt) Remote and local control functions customized for TSPS. 

(uit) Power supplied to external interface circuitry. 
(tv) Enclosure designed and stylized for a mounting location on the 
position accessible to the trainee. 

The reproducer is manufactured for the Bell System by an outside 
supplier. The prerecorded cassette training tape contains the voice and 
data associated with a maximum of 30 minutes of simulated calls. The 
tape contains two tracks, one for voice and the other for control tones 
(Fig. 7). In a position being used for training, the PROCON processes 
the cassette control tones, operator-keyed actions, and verbal re- 
sponses to simulate actual calls. The operation of the player is under 
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Fig. 4—Conversion of position to trainer. 


control of the PROCON, although the trainee has some manual override 
capability. The trainee now has the ability to load the cassette and 
initiate and pace the training session, which was not possible in the 
previous system. 

The control of the various components is shown in Fig. 8. The 
trainee inserts a prerecorded cassette in the reproducer and operates 
the play button. The cassette advances beyond a point where data, 
representing a TSPS lamp display, has been presented to the PROCON. 
A proper response by the trainee (either a key operation and/or verbal 
response) causes the PROCON to continue reading the tape. 

The control data on the cassette are formatted in a 5-bit baudot 
code representation. Each bit is represented by a different frequency 
on the tape. A coded 5-bit character is represented by combinations of 
one to four frequencies simultaneously. These frequencies are present 
for 80 ms as the tape advances at 1% inches per second (Fig. 7). A 20- 
ms interval is provided between consecutive characters as the tape 
advances. An instruction to the trainer generally is provided by two 
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Fig. 5—Architectural overview of PROCON. 


successive baudot characters although there are exceptions requiring 
only one. The data inputs are paired by PROCON and translated into a 
control function. For digital displays, telephone numbers are stored in 
the translator memory. There are standardized numbers for all trainees 
to use regardless of their location in the country. With this technique, 
a 10- to 12-digit display requires only a 2-character code. In addition, 
numbers keyed by the operator are stored in temporary memory. Both 
types of numbers can be displayed, when required, by operation of the 
corresponding display key at the operator’s console. Other digital 
displays, for example, time and charges, are pre-coded and can be 
displayed on demand. 

Operation of the time display key will produce a time-of-day display. 
When a position is powered up for the training function, the time is 
initialized to 8 o’clock. If desired, this can be changed by keying in the 
desired time on the keyset. 

Operation of a key on the console generates one of the 84 possible % 
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key codes. These % codes are identified by PROCON through its asso- 
ciated position interface circuit, and appropriate action is taken to 
control the cassette player, and light, flash, or extinguish lamps on the 
trainer console. 
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Verbal responses of the trainee are detected by a voice detector and 
forwarded to PROCON, which permits the call to progress to the next 
voice passage or group of data on the cassette tape. 

In addition to lamps and display data, the cassette tape data also 
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control tone signals (ziptone, audible ring, busy) to the trainee. These 
tones can be present for indeterminate time periods. For these types 
of signals, tone generators are provided under PROCON control. In 
general, these tones are initiated or terminated by the trainee key 
actions. 

The standard 100C operator position requires a 24-bit serial data 
word for each instruction to light a lamp or display pairs of numerical 
digits. In the 100C trainer, these 24-bit words are identical to those 
used on the standard 100C position but are generated by PROCON. As 
the trainee operates keys at the console, the % codes generated are 
translated and matched against expected results. If the correct re- 
sponse is made, the cassette is advanced to present new data. If a 
match is not made, the trainer does not respond, forcing the trainee to 
question his/her actions and give the correct responses. A flowchart of 
the operations of the 100C trainer is shown in Fig. 8. 

The 100C operator training system also includes an instructor’s 
console with an associated DATASPEED ® 40 printer to provide a 
record of trainee keying actions. The instructor’s console provides a 
means to supervise trainees while they are learning to handle Tsps 
traffic. It permits the instructor to monitor the simulated calls and the 
trainee’s responses. As keys are operated by the trainee, the corre- 
sponding lamps light on the instructor’s console. Incorrect key actions 
by the trainee cause the corresponding lamp to flash at the instructor’s 
console. 

The instructor can select any one of eight positions to monitor. 
While this one position is being monitored, all other seven positions 
are also being checked to determine if the trainees are making excessive 
errors in their responses. Excessive errors generated at a training 
position cause a corresponding position number lamp to flash at the 
instructor’s console. 

A DATASPEED 40 printer produces a record of the numbers keyed 
by the trainees. This can be done on a position-by-position basis by 
operation of a print key on the console. These records provide infor- 
mation on keying accuracy, as no actual matching of keyed numbers 
is provided in the 100C trainer programs. 

These trainers also require support facilities to provide training 
tapes. The production of these training tapes require the coordinated 
efforts of Bell Laboratories, AT&T, Western Electric and general trade 
suppliers. Initially, the efforts of BTL and the AT&T operator services 
organization are used to determine the correct operator actions and 
console displays required on calls. Once this has been determined, data 
codes required for new features are designed by BTL, and the infor- 
mation is provided to the operator training groups at AT&T. The 
necessary data patterns are then determined by the operator training 
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group and entered into the data base of the minicomputer-controlled 
support system used to produce master training tapes. 

To put both the data patterns and voice passages on master tapes, 
the support system called Automatic Data Entry Console (ADEC) was 
designed (Fig. 9), and two custom-built systems were provided to the 
AT&T training organization. This system has the capability of editing 
tapes and synchronizing the recording of voice and data to accurately 
simulate actual calls. It is updated and modified as required to provide 
new features. In order to produce master tapes, a narrative script is 
provided by the AT&T operator training organization to a professional 
recording studio which in turn produces a voice master tape. The voice 
master tape is used by the ADEC to generate the combined master tape 
consisting of voice passages and data tones on separate tracks. The 
generating of these tapes can call for several revisions to achieve 
realistic simulations (Fig. 10). 

The combined master tape provided by this system is then trans- 
mitted to Western Electric for quality control. Commercial suppliers 
provide cassette copies of the master tapes for use by the telephone 
companies. Tight specifications on the generation of the master tape 
and on the cassette duplication process are required to provide ade- 
quate operating margins in the use of audio cassette technology for 
the basic input to the control system. 

The use of the ADEC system has been beneficial in providing capa- 
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Fig. 9—ADEC system. 
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bilities for modifying and generating new training tapes not previously 
available with the older trainers. Requirements for training have been 
expanding continuously, and since the introduction of this system the 
production of training tapes has greatly improved. 
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